[Distutils] Proposal: "Install and save"
Nick Coghlan
ncoghlan at gmail.com
Sun Jul 24 10:23:20 EDT 2016
On 24 July 2016 at 13:50, Chris Angelico <rosuav at gmail.com> wrote:
> On Sun, Jul 24, 2016 at 12:53 PM, Nick Coghlan <ncoghlan at 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 | ncoghlan at gmail.com | Brisbane, Australia
More information about the Distutils-SIG
mailing list