Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[question] What about parsing requirements.txt? #11

Closed
rochacbruno opened this issue Aug 29, 2017 · 10 comments
Closed

[question] What about parsing requirements.txt? #11

rochacbruno opened this issue Aug 29, 2017 · 10 comments

Comments

@rochacbruno
Copy link

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.

@sebastianneubauer
Copy link

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...

@kennethreitz
Copy link
Collaborator

This is not considered good practice. I've done it in a few projects, but got yelled at for it.

@rochacbruno
Copy link
Author

@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?

@kennethreitz
Copy link
Collaborator

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.

@kennethreitz
Copy link
Collaborator

like i said, I've done it before :)

@webknjaz
Copy link

webknjaz commented Sep 3, 2017

@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.

@ofek
Copy link

ofek commented Sep 5, 2017

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

@kennethreitz
Copy link
Collaborator

kennethreitz commented Sep 5, 2017

Agreed, if that is your desired behavior.

@webknjaz
Copy link

webknjaz commented Sep 5, 2017

@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.

@kennethreitz
Copy link
Collaborator

agreed with @webknjaz

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants