On 03/18/2013 10:22 AM, PJ Eby wrote: > Actually, setuptools trusts redirects, so that mechanism is available > for splitting the hosted files to another domain.
By "trusts redirects" you mean that redirects bypass allow-hosts? This seems to contradict your line of argument up to this point (that allow-hosts must be simple and without exceptions or users will be confused). > As it stands, though, I don't see a way to support this without > introducing confusion. The advantage of using allow-hosts based on > the index host is that it *also* specifies what to do with dependency > links provided by individual packages; the PEP does not provide any > real guidance on this point. I'm updating the PEP to eliminate rel="external" (as it causes this confusion and provides no additional value) and clarify that any link, from anywhere, that is not rel="internal" should be considered an external link. > So, I have to withdraw my support for the PEP with these recent > changes, as it no longer reflects the approach I previously agreed to, > and as yet there have been no alternatives proposed to address the > user confusion issues (which IMO at least are a big part of the point > of having the PEP). I don't think there is any "user confusion" problem for an installer that does not already provide allow-hosts: just use a per-project "I want to trust external links provided by Django" option instead. And I don't really even think there is a user confusion problem in providing both allow-hosts and a new option on this model - they are options at different levels of abstraction and with different use cases (though I think the value of allow-hosts is weak if redirects bypass it anyway). IOW, this is not a problem with the PEP, this is a backwards-compatibility question and UI choice for easy_install maintainers. The PEP provides the right metadata, and there are reasonable options (in general) for installer UIs to make use of this metadata. Carl
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
