[Catalog-sig] V4 Pre-PEP: transition to release-file hosting on PYPI

Donald Stufft donald at stufft.io
Fri Mar 15 18:00:11 CET 2013


On Mar 15, 2013, at 12:51 PM, PJ Eby <pje at telecommunity.com> wrote:

> On Fri, Mar 15, 2013 at 12:07 PM, Carl Meyer <carl at oddbird.net> wrote:
>> On 03/15/2013 09:15 AM, PJ Eby wrote:
>>> Do we even need the internal/external rel info?  I was planning to
>>> just use the URL hostname.
>>> 
>>> i.e., are there any use cases for designating an externally-hosted
>>> file internal, or an internally-hosted file external?  If not, it
>>> seems the rel="" is redundant.
>> 
>> Right; Donald and Holger already gave the rationale for this: there are
>> good reasons for an index to not have "internal" links actually on the
>> exact same hostname. Even just using a different subdomain would break
>> simple host comparison.
>> 
>>> It's also more work to implement, vs. just defaulting --allow-hosts to
>>> be the --index-url host; a strategy ISTM pip could also use, since it
>>> has the same two options available.
>> 
>> Pip actually doesn't currently have --allow-hosts, although there's no
>> good reason for that; it ought to.
>> 
>>> Also, if we're not doing homepage/download crawling any more, I was
>>> hoping we could just drop the code that 'parses' rel="" links in the
>>> first place, as it's an awkward ugly hack.  ;-)
>> 
>> Well, parsing HTML links as an API is an ugly hack, but within that
>> existing framework "rel" seems like the appropriate semantic attribute
>> for this type of information, not really upping the hackiness quotient :-)
> 
> Well, to be clear, I liked previous versions of the proposal better
> than this one.  But while I *really* don't want to do any new rel
> parsing, that's not the only or even the most important reason.
> 
> The main reason is that I think internal vs. external is a bogus
> distinction: what's important (IMO) is what hosts you do and don't
> trust.  Giving a blanket pass to all external links doesn't seem like
> such a good idea to me, nor does allowing the index to define what
> hosts the client should trust.   As for the internal ones, I'm not
> sure why we can't at least make a subdomain requirement, or have users
> explicitly add a PyPI CDN to their configured --allow-hosts.
> 
> To try to put it another way: there should be one, and preferably only
> one, obvious way to specify where you get downloads from.  That way in
> easy_install is currently --allow-hosts.  Adding new options that
> interact and overlap with that looks like bad UI design to me,
> increasing the possibility of user confusion.
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig


You can do that fwiw. That's fine. You can optionally just use the internal links as a indicator about which hosts should automatically be added to the a--allow-hosts for a particular index.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130315/ce9f77cc/attachment.pgp>


More information about the Catalog-SIG mailing list