On 16 January 2018 at 20:22, Paul Moore <p.f.moore@gmail.com> wrote:
> On 16 January 2018 at 10:03, Nick Coghlan <ncoghlan@gmail.com> wrote:
>> On 16 January 2018 at 19:47, Paul Moore <p.f.moore@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@gmail.com | Brisbane, Australia
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig