[Distutils] Proposal: "Install and save"

[Nick Coghlan]

On 24 July 2016 at 00:04, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
> As I understand it, in the Javascript world package.json is used in both
> cases. Is that something Python should try to emulate? Is it hard to
> achieve given the limitations of setup.py that you pointed out?

There are other problems with the "one file to rule them all"
approach, one of which is that libraries should aim to be as loose as
is practical in declaring their dependencies, while applications
should treat dependency updates like any other code change: require
them to go through pre-merge CI by pinning an exact version of the
dependency in requirements.txt.

Donald wrote a good explanation of the distinction a few years ago:
https://caremad.io/2013/07/setup-vs-requirement/

The best current toolset I know for managing the distinction in the
case of an application venv or a user's ad hoc working environment is
actually pip-tools: https://github.com/nvie/pip-tools#readme

That splits the "explicitly declared application dependencies" out
into a requirements.in file, which pip-compile then turns into a
conventional (but fully pinned) requirements.txt file. The pip-sync
tool then says "make this environment exactly match this requirements
file".

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

(A full pip-sync wouldn't be appropriate though, since that may
uninstall dev requirements added via a separate requirements file)

I'm not sure it makes sense for pip itself though - pip's a bit more
neutral than that on precisely how people do their environment
management (even "pip install -r requirements.txt" is just an emergent
convention).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia