[Distutils] PEP 470 discussion, part 3

[Nick Coghlan]

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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia