vitessce-python
vitessce-python copied to clipboard
vitessce
Maybe dev dependencies should be in requirements.txt, not setup?
My sense is that the dependencies in setup are there for end users, and should be as loose as possible. For developers, though, I feel like requirements.txt may have a role: Specifying the dependencies precisely so behavior is reproducible during development.
I guess my question is whether the model of having lots of extras is based on someone's recommendation, or is it something we built for ourselves? I don't have a great depth of experience with this, so it'd be good for me to understand better how we got here.
We got here by moving the dependencies in https://github.com/vitessce/vitessce-python/pull/143. I have no issues with either the current setup.py model or the separate requirements file model (with a slight preference for conda and environment.yml over requirements.txt if going with the requirements file model). I also don't have a sense whether either model has major pros/cons over the other, besides the point made by @manzt in #143 that having different namespaces could support installing the minimal set of dependencies for a specific development task (e.g., docs vs linting vs testing).
But since we just moved them here from environment.yml, it feels like oscillating back and forth between the two models. If neither model is causing an issue for developers or end users then I think we should just stick with one, maybe documenting the choice so that we can point ourselves to the reasoning in the future.
I guess my question is whether the model of having lots of extras is based on someone's recommendation, or is it something we built for ourselves?
It's a pattern I've observed in several popular python projects, but nothing I've seen discussed formally anywhere:
- https://github.com/dask/dask/blob/ad898cf11c874c558e1a37c1c2210cb5ce07c6b4/setup.py
- https://github.com/napari/napari/blob/34bdc30655b4843a83d596a445a632b453171a22/setup.cfg
- https://github.com/tiangolo/fastapi/blob/9090c771eea9a51b17d0eb76dd060edd9f2e640e/pyproject.toml (via flit config in
pyproject.toml) - https://github.com/httpie/httpie/blob/69fe5dbfd10e5e58acf28478daa95246b338240e/setup.py
- https://github.com/fsspec/filesystem_spec/blob/c18902b278c18000cd93e54f0fb319602fa91e74/setup.py
Others seems to break up dependencies into separate requirements files, like like https://github.com/plotly/dash, https://github.com/zarr-developers/zarr-python, https://github.com/scipy/scipy, and numpy:
- https://github.com/numpy/numpy/blob/main/doc_requirements.txt
- https://github.com/numpy/numpy/blob/main/linter_requirements.txt
- https://github.com/numpy/numpy/blob/main/release_requirements.txt
- https://github.com/numpy/numpy/blob/main/test_requirements.txt
More "modern" python projects I've seem use poetry and specify (dev)deps in pyproject.toml.
- https://github.com/fedejaure/cookiecutter-modern-pypackage
- https://github.com/Textualize/rich/blob/1772458f80924c78fa3a8d0260bca9762ad86e18/pyproject.toml
But since we just moved them here from
environment.yml, it feels like oscillating back and forth between the two models. If neither model is causing an issue for developers or end users then I think we should just stick with one, maybe documenting the choice so that we can point ourselves to the reasoning in the future.
The https://github.com/jupyter-server/jupyverse repo seems similar to ours, in that there is an environment file minimally for configuring a conda environment with correct channels and pip and then all (dev)dependencies are specfied via install_requires + extra_requires.
- https://github.com/jupyter-server/jupyverse/blob/main/dev-environment.yml
- https://github.com/jupyter-server/jupyverse/blob/main/setup.cfg