[Distutils] workflow recommendations to update requirements.txt

[Chris Jerdonek]

On Wed, Dec 16, 2015 at 3:11 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 16 December 2015 at 16:40, Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
>> On Dec 15, 2015, at 8:56 PM, Chris Jerdonek <chris.jerdonek at gmail.com>
>> wrote:
>> Thanks for any help or suggestions.
>>
>>
>> This is what I'm doing right now (occasionally manually curating the output
>> of `pip freeze´) but I have heard good things about
>> https://github.com/nvie/pip-tools/ and I intend to investigate it.  As I
>> understand it, pip-compile is the tool you want.
>
> I just ran across pip-tools recently myself, and while I haven't
> actually tried it out yet, I think the design makes a lot of sense for
> the VCS-based deployment case:

Thanks Glyph and Nick for the suggestion to use pip-compile.  It
worked for me the first time with no issues.

The only thing I haven't decided on with that workflow is how to
manage potentially more than one requirements file for different
combinations of optional dependencies.  With the setup.py approach,
you can use "extras."  It looks like for pip-compile you can
accomplish this by having multiple *.in files (an additional one for
each "extra"), and invoking pip-compile with different combinations of
these files.

--Chris


>
> * you write a requirements.in file with your direct dependencies
> (including any pinning required for API compatibility)
> * pip-compile turns that into a requirements.txt that pins all your
> dependencies to their latest versions
> * pip-sync makes a virtualenv *exactly* match a requirements.txt file
> (installing, uninstalling, upgrading and downgrading as needed)
>
> That makes "upgrade dependencies" (by rerunning pip-compile) a clearly
> distinct operation from "deploy current dependencies" (by using
> pip-sync in an existing environment, or by installing into a fresh
> environment based on the generated requirements.txt).
>
> I'm not sure it makes as much sense in the case where the thing you're
> working on is itself a distributable Python package with its own
> setup.py - it seems like you'd end up duplicating information between
> setup.py and requirements.in.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia