https://dvc.org/doc/user-guide/contributing
Development environment of DVC can be setup by a number of methods like using Docker for installation, or using pipenv. @shcheklein should be add more methods in our Documentation.
Would you like to work on this?
Yes
@kurianbenoy sure, sounds good. I'm not sure about Docker as a dev environment though. Docker might be a good option to run something to test, but now as a dev environment - it would give too much overhead. We should provide simpler options for dev environments on all systems.
My perspective is to stick to the defaults, that means, using pip (and highly recommended, a virtual environment).
Docker could be really complicated (in term of "best practices"), it creates a lot of overhead (more knowledge required to run the project: how to mount a volume, compatibility with IDEs, connecting it with other remote services like SSH, etc.).
Also, Pipenv is really opinionated, I don't like it, but I understand that some people prefer it. The project, as it is right now, can be used with Pipenv without any additional modification (now, it reads the requirements.txt as a fallback, https://github.com/pypa/pipenv/issues/11#issuecomment-340485890).
In my experience, it is not a good idea to mess up with people's software development environment, as it is a really opinionated topic (e.g. https://en.wikipedia.org/wiki/Editor_war , OS war, etc.), it is better to stick to the defaults.
Anyways, that's my opinion, maybe the other maintainers hold another point of view.
I must recognize that Docker could help us to set up an environment to test specific remotes, like S3 (minio), Azure (azurite), etc.
It would be nice to support a docker compose file for those.
@kurianbenoy I do understand temptation of packing whole development environment into docker. In situations, when you have very complicated environment with lot of dependencies that might come in handy.
I also agree with guys that dvc is relatively simple project in terms of required dependencies, yet situations like https://github.com/iterative/dvc/issues/2008 happen. It is not stricte related to this discussion, but I mention it because even in such simple case as ours, dependency problems might happen.
If someone is interested in setting up environment, running tests and feels like developing in docker, who are we to stop him. Mentioning this in docs should be rather harmless. But there is one thing: before editing docs for such case, we should have separate repository with working build.
So, let's keep it simple for now.
Most helpful comment
@kurianbenoy I do understand temptation of packing whole development environment into docker. In situations, when you have very complicated environment with lot of dependencies that might come in handy.
I also agree with guys that dvc is relatively simple project in terms of required dependencies, yet situations like https://github.com/iterative/dvc/issues/2008 happen. It is not stricte related to this discussion, but I mention it because even in such simple case as ours, dependency problems might happen.
If someone is interested in setting up environment, running tests and feels like developing in docker, who are we to stop him. Mentioning this in docs should be rather harmless. But there is one thing: before editing docs for such case, we should have separate repository with working build.