[Distutils] pipenv use cases

[Brett Cannon]

On Tue, 16 Jan 2018 at 02:45 Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 16 January 2018 at 20:22, Paul Moore <p.f.moore at gmail.com> wrote:
> > On 16 January 2018 at 10:03, Nick Coghlan <ncoghlan at gmail.com> wrote:
> >> On 16 January 2018 at 19:47, Paul Moore <p.f.moore at 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
> > it stands).
> >
> > 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.
>
> Yes, that's deliberate. We want to target app developers as our
> initial audience, since library and framework developers have
> different needs (and for folks just starting out with library
> development, pipenv + the latest version of Python is actually fine -
> matrix testing only comes into play once folks actually want to
> support older versions, perhaps because the version they started out
> with is no longer the latest one).
>

Is there a library developer workflow that's being promoted then somewhere
that I'm just not finding? Or does that need to be written for
packaging.python.org (which I *might* be willing to write; see below for
motivation)?

At least from a VS Code perspective it would be great to have a target of
supporting the workflows as documented at packaging.python.org so people
know how they should generally structure things as well as making sure VS
Code always supports the modern workflows. Also being able to say "your
workflow is not normal" is also always helpful when dealing with feature
requests. :)

-Brett


>
> > 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.
>
> As I noted in my original comment, pipenv only applies to library and
> framework development insofar as you can treat your test suite as an
> "app" to be deployed to developer's machine (the deployment mechanism
> is "git clone", but it's still a deployment).
>
> Where that currently breaks down is as soon as you're testing across
> multiple versions, where the combination of wheel files and
> environment markers means the current lock file format runs into
> trouble (but so do requirements files).
>
> > 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...
>
> Local build dependencies are within scope, but pipenv doesn't
> magically fix the development resource constraint problem :)
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180116/ae5469f3/attachment-0001.html>