[Distutils] PEP 470 discussion, part 3

Daniel Holth dholth at gmail.com
Fri Jul 25 15:54:09 CEST 2014

On Fri, Jul 25, 2014 at 9:49 AM, Donald Stufft <donald at stufft.io> wrote:
> On July 25, 2014 at 9:43:28 AM, Nick Coghlan (ncoghlan at gmail.com) wrote:
> On 25 July 2014 23:34, Donald Stufft <donald at stufft.io> wrote:
>> On July 25, 2014 at 9:29:14 AM, Richard Jones (r1chardj0n3s at gmail.com)
>> wrote:
>> On 25 July 2014 15:21, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> On 25 July 2014 23:13, Richard Jones <r1chardj0n3s at gmail.com> wrote:
>>> > A variation on the above two ideas is to just record the *link* to the
>>> > externally-hosted file from PyPI, rather than that file's content. It
>>> > is
>>> > more error-prone, but avoids issues of file ownership.
>>> This is essentially what PEP 470 proposes, except that the link says
>>> "this project is hosted on this external index, check there for the
>>> relevant details" rather than having individual links for every
>>> externally hosted version.
>> Well, not quite. The PEP proposes a link to a page for an index with
>> arbitrary contents. The above would link only to packages for the /simple/
>> name in question. A very small amount of protection against accidents but
>> some protection nonetheless. Also, an installer does not need to go to
>> that
>> external index to find anything - everything is listed in the one place.
>> This is still a second mechanism that users have to know and be aware of.
>> The multi index support isn’t going away and it is the primary way to
>> support things not hosted on PyPI in every situation *except* the “well I
>> have a publicly available thing, but I don’t want to upload it to PyPI for
>> whatever reason” case. As evidenced by the numbers I really don’t think
>> that
>> use case is a big enough use case to warrant it’s own special mechanisms.
>> Especially given the fact that it forces some bad architecture on the
>> installers.
> The Linux distros have honed paranoia to a fine art, and even we don't
> think maintaining explicit package<->repo maps is worth the hassle,
> especially when end-to-end package signing is a better solution to
> handling provenance concerns.
> If people are especially worried about it (especially given we don't
> have generally usable end-to-end signing yet), then a simpler solution
> than package <-> repo maps is to have repo (or index, in PyPI
> terminology) priorities, such that packages from lower priority repos
> can never take precedence over those from higher priority repos.
> With yum-plugin-priorities, repos get a default priority of 99, and
> you can specify an explicit priority in each repo config. This can be
> used to have a company internal repo take precedence over the Red Hat
> or community repos, for example.
> Not that this solves it generically, but I’ve toyed with the idea of a
> requirements 2.0 file format that included constructions that said things
> like “for this dependency, mandate it come from a particular index” or the
> like.

There was a similar idea in the wheel signatures scheme, where you
would include the public keys of the allowed signers alongside the
dependency name. The system would have allowed you to install
particular built dependencies but only if they were signed by one of a
set of signers, preventing you from accidentally installing the wrong
thing. At the time I'd proposed extending the array access syntax
packagename[keyidentifier=xyzabc...] used for extras.

More information about the Distutils-SIG mailing list