Consolidate files listing dependencies

Currently, the following files all list torchgeo’s dependencies:

• setup.cfg
• requirements.txt
• docs/requirements.txt
• spack.yaml
• environment.yml
• .github/workflows/{docs/release/style/tests}.yaml
• .pre-commit-config.yaml

Whenever someone needs to add a new dependency to torchgeo, they need to add it to most of these files, making it easy to forget and difficult to keep track of. We should try to consolidate these. Here are some suggestions:

setup.cfg

We may be able to use requirements.txt instead of setup.cfg by using something like pbr or setuptools-scm. But see below for another option.

requirements.txt

I don’t think this file is necessary. pip install .[all] in the root directory should read the dependencies from setup.cfg and provide much of the same support as pip install -r requirements.txt. I think pip install git+https://github.com/microsoft/torchgeo may also work.

docs/requirements.txt

This can be removed pending https://github.com/pytorch/pytorch_sphinx_theme/issues/143

spack.yaml

This can be removed by adding a py-torchgeo package to Spack. It can install both stable releases (once we release) as well as development versions.

environment.yml

I’m not sure how to remove this one. Can conda-forge be used to install development versions?

.github/workflows/{docs/release/style/tests}.yaml

If we pip install all of our dependencies from requirements.txt, it will be slower than only installing the deps for a specific tests, but we won’t have to duplicate info as much.

.pre-commit-config.yaml

No ideas, the developers don’t seem interested in sharing configuration files with any other tool: https://github.com/pre-commit/pre-commit/issues/1165

[adamjstewart]

Gotcha. I think a lot of developers (especially @calebrob6) prefer conda. Personally I use Spack. And a lot of people just want to use pip. I think supporting more package managers than that would add more headaches.

[ashnair1]

Perhaps better is too strong a word. Convenient would be more appropriate. Poetry doesn’t replace conda. conda manages environments and resolves dependencies whereas poetry only does the latter. The key here is how a project uses conda. Is it used for environment management? Installing specific non-python libraries? Both?

I mainly used conda for environment management and I preferred poetry because:

• Manual update and maintenance of environment.yml With conda I needed to maintain an environment.yml file and had to manually update it for every package I added. With poetry I can keep adding dependencies via poetry add which updates pyproject.toml and the poetry.lock file (for transitive dependencies) and go about my work. Also one less file for me to maintain.

• conda is generally slower. This isn’t a knock against conda since it’s scope extends beyond python and python packages. But due to this, it takes a while for dependencies to be resolved. poetry is a dependency manager for python and I’ve found it to be faster to set up an environment when I work with python projects.

Misc issues:

• Need to keep track of conda-forge and pypi versions.
• Cross platform environments

Poetry and pyenv together gives me enough environment management without the overhead of maintaining an additional file of dependencies and tracking a separate package registry (conda-forge). Here I prefer to use two specialised tools over a single massive one.

That being said, for projects that utilise non-python libraries (like GDAL for example), I would still use conda.