On 24 July 2016 at 13:50, Chris Angelico <ros...@gmail.com> wrote: > On Sun, Jul 24, 2016 at 12:53 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >> Personally, I could definitely see a feature like "pip-newdep >> requirements.in '<dep1>' '<dep2>'" being relevant in pip-tools as a >> shorthand for something like: >> >> echo '<dep1>' >> requirements.in && echo '<dep2>' >> >> requirements.in && pip-compile requirements.in && pip install -r >> requirements.txt > > Can the file name be made implicit?
"requirements.in" is the default in pip-compile if you don't otherwise specify a source file, so yes, you could rely on that. However, I'm not really the right person to ask - that would be Vincent Driessen, as the author of pip-tools :) > and it'd DTRT as regards building the requirements. If I understand > you correctly, requirements.in would store only the names of packages > required (no version info), You can still put version constraints in requirements.in, but they'd generally only be for known incompatibilities (i.e. minimum versions, plus sometimes maximum versions if there's a backwards compatibility break) > and then requirements.txt would look like > the output of 'pip freeze' but only for the packages listed in > requirements.in? Because that would be _perfect_. Both files go into > source control, and the task "update to the latest versions of things > and check if it all works" would be straight-forward. Yep, and if I understand the logic correctly, "pip-compile" will add new dependencies, but leave existing ones alone if they still meet the requirements, while "pip-compile --upgrade" will try to upgrade everything to the latest version. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig