[Distutils] pipenv best practices?

[Chris Withers]

On 16/01/2018 04:24, Nick Coghlan wrote:
> 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

Thanks!

>>> 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?
>>
> "pipenv --venv" gives the path for the current project, so what I tend
> to do is run "ln -s $(pipenv --venv) .venv" from the directory
> containing Pipfile and Pipfile.lock in order to create a deterministic
> path name.

Hmm, that feels hacky. It doesn't feel like there's consensus on this 
issue, and there's enough dupes coming in that it feels a shame that 
https://github.com/pypa/pipenv/issues/1049 has been closed.

I actually want both use cases in different scenarios. For dev, I 
typically want one venv per python version (how do I do that?) somewhere 
central. For deployment, I want a ./.venv or ./ve right next to the Pipfile.

>>> 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).
>>
> 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/)

As an aside: I find the doc split difficult. Even as a relatively 
experience python dev, knowing that I wanted to figure out what pipenv 
does and how to use it, I started at 
http://pipenv.readthedocs.io/en/latest/ which has no links to the 
tutorial(s).

> 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

I'm afraid I don't know enough about pipenv internals to understand the 
implications of the above, or why you might want to change the commit 
has to the project name, and indeed, what the implications of that might be.

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

Where can I find out more about [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),

...or a .travis.yml axis for CI, or just separate venvs for local dev, 
in my case...

> the best current approach is to use "pipenv
> lock --requirements" to export just the library dependencies from
> Pipfile.lock. 

...but what do I do with Pipfile.lock then? .gitigore?

cheers,

Chris