[Distutils] PEP 470 discussion, part 3

[Donald Stufft]

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.

-- 
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140725/8d07ac86/attachment.html>