[Distutils] pipenv best practices?

[Paul Moore]

On 16 January 2018 at 08:08, Chris Withers <chris at withers.org> wrote:
>> 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.
>
>
> Well, kinda, pipenv is shaping up to be the "replacement" for
> pip+virtualenv, where the latter becomes just an implementation detail.
> Would be great if it had a good story for that use case :-)

I think the big issue is that it's not clear what use cases pipenv is
*trying* to address. Your description of it being a "replacement" for
pip+virtualenv is more or less what I originally assumed it was
intended to be. But I tripped over this a while back, when I found it
very difficult to use pipenv on a project where I needed to:

1. Reference an unreleased version of a project from github
2. Have one of its dependencies be satisfied from a locally (within
the project directory) stored copy of a wheel, as there was no
suitable wheel on PyPI.

I can't recall the details - they are in various issues on the pipenv
tracker - but it was clear that I was trying to do something that
wasn't considered "expected use" of pipenv, and I was getting very
frustrated by the workarounds I needed to use to support my
requirements. The guys on the pipenv tracker were very helpful, but
when you're hitting design limitations, you can't expect quick fixes,
so I ended up going back to pew + requrements.txt.

I think that if the pipenv docs had some better guidance on what use
cases it was intended to cover (and what it wasn't, in relation to the
broader range of pip+virtualenv use cases) that would help people
better understand its place in the ecosystem.

Paul