On 16 January 2018 at 10:03, Nick Coghlan <ncoghlan(a)gmail.com> wrote:
> On 16 January 2018 at 19:47, Paul Moore <p.f.moore(a)gmail.com> wrote:
>> 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.
> That's fair, and making the PyPUG tutorial specifically about
> *application* dependency management was an initial step in that
> direction - for the library development use case, you're generally
> going to step out of pipenv's world as soon as you try to run your
> tests across multiple versions.
> The basic usage constraint is that pipenv expects you to control your
> target Python version, and it expects you to have exactly one - to go
> beyond that (as is needed for multi-version library support), you'll
> still need to drop down to the lower level tooling, either skipping
> the use of pipenv entirely, or else by using `pipfile lock
> --requirements` to shift levels.
New subject as I don't want to hijack the original thread to rehash my
old issue, but I do want to make a couple of points on this (and I
agree, it's hard to find a good forum to discuss things like this as
1. "pipenv expects you to control your target Python version" - I'm
not 100% sure what that means, but if it's saying "pipenv is only
really for code that will only be used with a single Python version"
then that's basically excluding a huge chunk of Python development.
Specifically, library development of all forms. Admittedly my
experience of what's "typical" is biased strongly by the communities I
work with, but conversely the "writing standalone apps in Python"
community doesn't really seem to have a web presence that we can
promote pipenv through, so it's becoming visible via the "general
Python development" community, which quite biased to libraries, and so
is not the right target audience, from what you say.
2. My specific issues weren't outside that constraint - I *was*
writing code that would only ever need to run under Python 3.6. My
problem was the need for "local" build dependencies, which seems
entirely within that use case. In fairness, the pipenv devs weren't
totally against the functionality I needed, it's just not something
they had considered important. Maybe the problem here is that there
isn't a good set of "developing apps in Python" best practices (as
opposed to the library development situation - use install_requires,
test with tox, ...), so I didn't know the "recommended" solution to my
problem, that pipenv would have been expecting me to use. Maybe it's a
chicken-and-egg situation - the "best practice" is to use pipenv, but
until pipenv gets to encounter all the various use cases, that "best
practice" doesn't properly cover every situation...