separating dependencies into requirements*.txt?
gliptak opened this issue · 14 comments
An example is at:
https://github.com/pydata/pandas-datareader/blob/master/setup.py#L17
Please let me know if you are open to a PR updating setup.py as above.
I would not advocate for that. What is the motivation for it?
Motivation is that a developer or developer tooling can run pip installl using requirements*.txt files and setup.py stays in sync. You see many projects listing out-of-sync dependencies between their requirements and setup.py
That does not seem like a typical usage of requirements.txt (related: https://caremad.io/posts/2013/07/setup-vs-requirement/).
pip install . (or tox --devenv) will install anything in install_requires without the need for a requirements.txt.
Why do you need both?
Hi @gliptak, thanks for the suggestion. I would also argue that this is an anti-pattern, and that we won't plan to support something similar here. I'd recommend reading https://caremad.io/posts/2013/07/setup-vs-requirement/.
Thank you for the great link.
So maybe above style requirements.txt is to be added to the project?
Also are pip install flags targeting load of requirement-dev and requrements-test dependencies directly from setup.py?
IMO, tox runs the show for dev and test, so those dependencies should go in a deps section. You can get a virtualenv with those deps by running tox --devenv, optionally with -e if you have multiple environments (e.g. one for static analysis). I do not use setup.py test (or any other setuptools command directly).
Sharing my own experience.
I also use tox's deps section but it references a requirements-dev.txt file. The reason for the separation is that while I use tox as a final step just before committing and pushing a change, I use pytest via test.vim to do very quick and selective execution of tests while I'm coding (relevant part of my dotfiles) because tox is just too slow for me.
In order for me to do the above while avoiding duplicated dependency declarations everywhere, I keep the dev devepencies in that requirements-dev.txt file while the runtime dependencies stay in setup.py. Here's one of my pet projects that exemplifies the structure: https://github.com/relaxdiego/aircraft
Maybe workflow best practice highlights could be added to README
@relaxdiego Do you manually create a virtualenv or does test.vim do that for you?
@dmtucker I manually create it. Starting in this part of the readme, one can either use pyenv (my preference) or the more widely accepted (I think) venv style.
Gotcha... Seems like tox --devenv in multiple steps 🤔
@dmtucker it is, yes. My motivation for doing it that way though is because when I code, I have vim do split windows where the left window is my test file and my right window is my code. I will jump between windows frequently and I test often. Using tox for this produces a lag that adds up over time whereas pytest does not. That's why I avoid using tox up until the very last step just before I commit my changes.
Would you not just call tox --devenv once, then use pytest the same way you currently do?
tox --devenv ./venv
venv/bin/pytest ...
venv/bin/pytest ...
source venv/bin/activate
pytest ...
pytest ...sure that works too, especially for those that like the venv style. i'm partial to pyenv though since i always forget to run that source ... part. :-)