[Distutils] distlib and wheel metadata

[Nick Coghlan]

On 24 February 2017 at 01:27, Paul Moore <p.f.moore at gmail.com> wrote:

> On 23 February 2017 at 15:09, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > The difference is that:
> >
> > * tool = you typically want at least one copy per Python interpreter
> (like a
> > library)
> > * application = you typically only want one copy per system
> >
> > It may be clearer to make the former category "devtool", since it really
> is
> > specific to tools that are coupled to the task of Python development.
>
> Ah, OK. That's a good distinction, but I'd avoid linking it to "used
> for developing Python code". I wouldn't call pyline something used for
> developing Python code, although you'd want to install it to the
> (possibly multiple) Python versions you want to use in your
> one-liners. OTOH, I'd agree you want copies of Jupyter per
> interpreter, although I'd call Jupyter an application, not a
> development tool. There's a lot of people who would view Jupyter as an
> application with a built in Python interpreter rather than the other
> way around. And do you want to say that Jupyter cannot pin
> dependencies because it's a "tool" rather than an "application"?
>

It provides a frame for a discussion between publishers and redistributors
on how publishers would like their software to be treated.

Marking it as an application is saying "Treat it as a standalone
application, and don't try to integrate it with anything else"

Marking it as a library is saying "Treat it as a Python component that
expects to be integrated into a larger application"

Marking it as a metapackage is saying "Treat this particular set of
libraries as a coherent whole, and don't try to mix-and-match other
versions"

Marking it as a devtool is saying "This doesn't export a stable Python API
(except maybe to plugins), but you should treat it as a library anyway"

Redistributors may *ask* a publisher to reclassify their project as a
library or a devtool (and hence also avoid pinning their dependencies in
order to make integration easier), but publishers will always have the
option of saying "No, we want to you to treat it as an application, and we
won't help your end users if we know you're overriding our pinned
dependencies and the issue can't be reproduced outside your custom
configuration".

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170224/cb230453/attachment.html>