[Distutils] pipenv use cases

[Nick Coghlan]

On 17 January 2018 at 05:21, Brett Cannon <brett at python.org> wrote:
> Well, technically we need consensus so we agree that what goes up on
> packaging.python.org makes sense; I'm not worried about the whole world. :)
> I mean I'm not even after specifically recommended testing practices and
> such since that seems outside the realm of packaging.python.org. I'm more
> interested in e.g. how should people handle venvs when they support more
> than one version of Python? Documenting not pinning your dependency
> versions. How do you specify what is required for testing and such so that
> you can generically know how to get those dependencies installed in your
> venv if you don't want to have your eventual wheel to include those
> test-only dependencies? Basically I'm after a tutorial on how to handle
> packaging while developing a library. I view "use tox, use pytest" as
> something under TIP's purview to create a tutorial/guide for.

Right, one of the things we worked out when Jon wrote the pipenv-based
application dependency management guide was that "Install this library
to my user directory so that I, the human Nick Coghlan, can use it in
my personal scripts" is a different task from declaring application
dependencies, and the subsequent feedback we've received (including
this thread) shows that library/framework dependency management is
slightly different again (and dependency management for portable
applications that work across multiple Python versions will look more
like the latter than the former).

I think tox provides a good precedent for what's needed when it comes
to effectively targeting multiple environments: you want a venv per
target environment per project, not just a venv per project.

However, while that's a configuration I'd personally like to see us
better *enable* in pipenv, I wouldn't want it to come at the expense
of the core notion of a "preferred deployment environment" as
represented by Pipfile.lock, and I'd also prefer that it didn't come
at the expense of making the lock file format itself more complex.

One way we could do that is to add a "--lockfile" option to both
"pipenv lock" and the "pipenv sync" subcommand proposed in
https://github.com/pypa/pipenv/issues/1255, and a "--venv" option to
the latter, such that the workflow for libraries/frameworks/portable
applications would be:

* use Pipfile/Pipfile.lock as normal for your "recommended development
environment" (e.g. the most recent supported Python version for access
to the most up to date developer tools, or perhaps the oldest
supported Python version to minimise the risk of breaking
compatibility). The "interactive" pipenv subcommands (install,
uninstall, update, run, shell) would all continue to work specifically
on the default lock file and venv.
* use "pipenv lock --python TARGET --lockfile PATH_TO_TARGET_LOCKFILE"
to generate target specific lockfiles for other environments
* use "pipenv sync --lockfile PATH_TO_TARGET_LOCKFILE --venv
PATH_TO_TARGET_VENV" to configure virtual environments based on those
alternate lock files

Cheers,
Nick.

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