Re: V4 Pre-PEP: transition to release-file hosting on PYPI

--===============0338039494==
Content-Type: multipart/signed; boundary="Apple-Mail=_34E62873-19E7-486E-9D1A-2B28FA2C54AA"; protocol="application/pgp-signature"; micalg=pgp-sha1


--Apple-Mail=_34E62873-19E7-486E-9D1A-2B28FA2C54AA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Mar 15, 2013, at 12:51 PM, PJ Eby <[email protected]> wrote:

> On Fri, Mar 15, 2013 at 12:07 PM, Carl Meyer <[email protected]> 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.
>>>=20
>>> 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=3D"" is redundant.
>>=20
>> 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.
>>=20
>>> 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.
>>=20
>> Pip actually doesn't currently have --allow-hosts, although there's =
no
>> good reason for that; it ought to.
>>=20
>>> Also, if we're not doing homepage/download crawling any more, I was
>>> hoping we could just drop the code that 'parses' rel=3D"" links in =
the
>>> first place, as it's an awkward ugly hack.  ;-)
>>=20
>> 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 :-)
>=20
> 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.
>=20
> 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.
>=20
> 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
> [email protected]
> 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


--Apple-Mail=_34E62873-19E7-486E-9D1A-2B28FA2C54AA
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)

iQIcBAEBAgAGBQJRQ1OcAAoJEG48vOkzctz69dUP+gJHcps2iVrKw+eNbz+w77Jy
azNIaidcwPCpmfvSSn966ErkhttbjQwGqCT1P/ZEqfXhR3GB3PkOrSEXlfTHbQn6
KBaK1YOpt/rFCZ66tzgioGCQWHax+5rlrwwD6X9qkjJwwwek8d1hKbJUAS3JGmCp
+N2+hFH+WXtbLNHe698EBpUEntlo4qnyj8zaw8OUP540dLePZL8A8/f6m29DuEjO
ZSgv5TwIvNa/vHx21OOnp44Rba1Laqe9raVb/cUaXA1u+GdVOJsLuCZYpBzlFhLt
JXCsgJrcn0QpWtLWYD02IPR2embOxUPUalU+nMWTPr3qxHb0fId7jvsGS2tQ32/A
TA/Loih3aEtWHVJ1fyFkhjlpV3/6654VfQFH44EaWbmE317OkAd3yVXIx4MKEPHQ
MOJMkgQXNYfLlaHhx4fKn4Q2ffaq4a8eXPu9+FSEcCskmQ1yOuyh2ZNfDaxRQ0xU
n7EL43ODP1HusyJelNiYBf8VCoHkNYJgdlC5jwGTsIU+CuPhucTp/0OnmssHXy0Z
ytMZKyhQsqH8oV/4tPRYSvBWkEkZpcmHHdUJdyLVWxAhsXud45OuqOQY1mH1Pt6l
rNXd6E62xhUDKdeCs196jZx/v1yoLzJYOu4KX8+FqgV1Gr7qJGogQfERe3stu/CJ
LGRIMRA8gI34EbEC+dVL
=zacT
-----END PGP SIGNATURE-----

--Apple-Mail=_34E62873-19E7-486E-9D1A-2B28FA2C54AA--

--===============0338039494==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig

--===============0338039494==--