[Distutils] pipenv use cases

[Brett Cannon]

On Tue, 16 Jan 2018 at 10:43 Paul Moore <p.f.moore at gmail.com> wrote:

> On 16 January 2018 at 17:36, Brett Cannon <brett at python.org> wrote:
> > 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)?
>
> Possibly not as such, but there's a fairly broad consensus over such
> things as:
>
> * Use tox to test your code against the versions you want to use
> * Declare dependencies with install_requires and leave the version
> requirements loose
>
> Maybe some other things I'm not thinking of right now. But basically
> most projects I see use a broadly similar structure, and they are all
> libraries. There's nowhere near as many good examples of Python
> applications that I know of, and little obvious consensus (for
> example, there's nothing I've ever seen that suggests a "standard"
> method of deploying applications - the nearest thing I know of is
> "write the app as a library and use a console entry point", which is
> pretty much the opposite of a separate app development standard :-)
>
>
> > 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. :)
>
> That's my feeling too - if we have reasonable community consensus on
> "normal workflows", it's a lot easier to define boundaries on what
> applications like pipenv or VS Code will support. Consensus is hard to
> come by, though...
>

Well, technically *we* need consensus so we agree that what goes up on
packaging.python.org makes sense; I'm not worried about the whole world. :)
I mean I'm not even after specifically recommended testing practices and
such since that seems outside the realm of packaging.python.org. I'm more
interested in e.g. how should people handle venvs when they support more
than one version of Python? Documenting not pinning your dependency
versions. How do you specify what is required for testing and such so that
you can generically know how to get those dependencies installed in your
venv if you don't want to have your eventual wheel to include those
test-only dependencies? Basically I'm after a tutorial on how to handle
packaging while developing a library. I view "use tox, use pytest" as
something under TIP's purview to create a tutorial/guide for.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20180116/bb67a8f9/attachment-0001.html>