[Distutils] pipenv best practices?

[Nick Coghlan]

On 16 January 2018 at 05:46, Brett Cannon <brett at python.org> wrote:
> On Mon, 15 Jan 2018 at 00:33 Chris Withers <chris at withers.org> wrote:
>>
>> Hi All,
>>
>> Couldn't find an obviously better discussion forum than this for pipenv
>> stuff, but please point me to where the rest of the discussions are
>> happening...
>
>
> Not here from what I can tell. :) Probably your best bet is to ask on the
> pipenv GitHub project and file an issue so the pipenv docs can give you
> guidance. I know for me personally it's getting a bit hazy between this list
> and pypa-dev where stuff should go (I'm personally starting to shift towards
> pypa-dev and considering this actually for distutils proper).

Personally, I don't think mailing lists in general are a great medium
for asking usage and support questions.

Anyway, we genuinely don't have a clear answer to this question, so
I've posted a meta-issue on the pipenv tracker to decide how we want
to handle it: https://github.com/pypa/pipenv/issues/1305

>> Continuing on the deployment theme: I'm used to being able to put
>> /path/to/some/ve/bin/some_script in crontabs and the like, where
>> some_script comes form a setuptools entry point.
>> What's the canonical way of doing this with pipenv?
>
> Beats me. I think there's a command to get back to the venv that pipenv
> created on your behalf.

"pipenv --venv" gives the path for the current project, so what I tend
to do is run "ls -s $(pipenv --venv) .venv" from the directory
containing Pipfile and Pipfile.lock in order to create a deterministic
path name.

>> Last up, how should pipenv be used for library development? (ie: where
>> dependencies and minimal constraints are expressed in setup.py and where
>> you want to test against as many python versions and library
>> combinations as you support).
>
> That doesn't fall under pipenv's purview. Think of pipenv as trying to make
> venv + pip easier to work with. Since you don't use pip to express
> dependencies for your library then you shouldn't with pipenv either. Or put
> another way, think of your pipfile as just a different format for a
> requirements.txt file, not a replacement for flit or setuptools.

pipenv does cover this case to some degree - the trick is that it
involves thinking of your library's *test suite* as the application
you want to deploy. (Hence the reference to "development and testing
environments" at the end of the intro to
https://packaging.python.org/tutorials/managing-dependencies/)

For that case, you don't put *any* of your dependencies from
`setup.py` into `Pipfile`, you just run "pipenv install -e src", which
will give you a Pipfile entry like:

   "<commit-hash>" = {editable = true, path = "src"}

I personally then edit that entry to replace the commit hash with the
actual project name

All the testing and linting dependencies then go under [dev-packages].

The part you can't fully rely on yet is the lock file, since that aims
to lock down the version of Python as well, not just the versions of
the Python level dependencies. So if you're testing across multiple
versions (e.g. with tox), the best current approach is to use "pipenv
lock --requirements" to export just the library dependencies from
Pipfile.lock. That's an area that could definitely use some UX
improvement, but it isn't clear to me at this point what that would
actually look like (short of adding a notion of named "install
profiles" to the lock file format, which could then be aligned with
tox test environments).

Cheers,
Nick.

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