[question] What about parsing requirements.txt?
rochacbruno opened this issue · 10 comments
https://github.com/kennethreitz/setup.py/blob/c5a82dc3670b5fa65e4d5da578d992c38b62d524/setup.py#L22
2 years ago I was playing with this http://j.mp/setup_py and one of the features is using pip.req.parse_requirements('requirements.txt') to populate the requires and avoid duplicity.
What do you think about this? on advantage of having a requirements.txt is to use pyup.io and satefy to check updates and audit the requirements for security failures.
This is a pretty crucial feature. As we all know, pip is not perfect at dependency resolution. Therefore, for serious workflows one needs to be able to parse and resolve the requirements with external tools like pip-tools, especially pip-compile. For this workflow, having a requirements file which is only parsed by setup.py is extremely usefull...
This is not considered good practice. I've done it in a few projects, but got yelled at for it.
@kennethreitz so it is better practice to maintain a duplicated requirements list? one on setup.py and other on requirements.txt to enable the tools mentioned above?
requrements.txt is for bootstrapping environments (e.g. with pinned dependencies), setup.py is for installing packages — they are separate tools for separate tasks.
You are certainly free to merge them for your own needs, but this repo won't do that.
like i said, I've done it before :)
@rochacbruno take a look at pbr if you need this, but you should first consider having a single place of requirements, if you need to group optional requirements in distribution package, there's extras_require for this purpose.
I know this is closed but just so everyone knows: the current best practice it to put -e . at the top of requrements.txt. From https://caremad.io/posts/2013/07/setup-vs-requirement/
https://github.com/ofek/hatch does this for new projects by default
Agreed, if that is your desired behavior.
@ofek I think it is only good for application projects, which are meant to be installed in --editable mode in production. I wouldn't recommend it for library packages, nor I recommend mixing setup.py with requirements.txt. They've got different purposes of existence. If you want to freeze versions of sub-dependencies, consider using --constraints pip command-line argument, so you won't mix them with real requirements.
agreed with @webknjaz