On 17 February 2017 at 23:18, Jeremy Stanley <fungi@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@gmail.com | Brisbane, Australia