[Distutils] distlib and wheel metadata

Nick Coghlan ncoghlan at gmail.com
Thu Feb 23 03:33:57 EST 2017


On 17 February 2017 at 23:18, Jeremy Stanley <fungi at yuggoth.org> wrote:

> On 2017-02-17 09:56:04 +0100 (+0100), Nick Coghlan wrote:
> [...]
> > So if we rely on a manual "publish with pinned dependencies", "get bug
> > report from redistributor or app developer", "republish with unpinned
> > dependencies", we'll be in a situation where:
> >
> > - the affected app developer or redistributor is going to have a negative
> > experience with the project
> > - the responsible publisher is either going to have a negative
> interaction
> > with an end user or redistributor, or else they'll just silently move on
> to
> > find an alternative library
> > - we relinquish any control of the tone used when the publisher is
> alerted
> > to the problem
> >
> > By contrast, if we design the metadata format such that *PyPI* can
> provide
> > a suitable error message, then:
> >
> > - publishers get alerted to the problem *prior* to publication
> > - end users and redistributors are unlikely to encounter the problem
> > directly
> > - we retain full control over the tone of the error notification
> [...]
>
> It seems like the same could be said of many common mistakes which
> can be identified with some degree of certainty through analysis of
> the contents being uploaded. Why not also scan for likely security
> vulnerabilities with a static analyzer and refuse offending uploads
> unless the uploader toggles the magic "yes I really mean it" switch?
> Surely security issues are even greater downstream risks than simple
> dependency problems. (NB: I'm not in favor of that either, just
> nudging an example in the reductio ad absurdum direction.)
>

Most of the other potential checks are about forming an opinion about
software quality, rather than attempting to discern publisher intent.

Now, we could ask all package developers "Is this an application, service,
or metapackage?", but then we'd have to get into a detailed discussion of
what those terms mean, and help them decide whether or not any of them
apply to what they're doing. It would also be a complete waste of their
time if they're not attempting to pin any dependencies in the first place,
or if they're not publishing the component to a public index server.

Alternatively, we can defer asking any question at all until they do
something where the difference matters: attempting to pin a dependency to a
specific version when publishing to a public index server. At that point,
there is an ambiguity in intent as there are multiple reasons somebody
could be doing that:

- they're actually publishing an application, service, or metapackage, so
dependency pinning is entirely reasonable
- they've carried over habits learned in application and service
development into component and framework publishing
- they've carried over habits learned in other ecosystems that encourage
runtime version mixing (e.g. npm/js) into their Python publishing

So the discussion in this thread has convinced me that a separate
"allow_pinned_dependencies" flag is a much better way to model this than
attempting to define different dependency types, but I still want to
include it in the metadata model :)

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/20170223/3381ce17/attachment.html>


More information about the Distutils-SIG mailing list