On 12 May 2014 09:35, "Donald Stufft" <don...@stufft.io> wrote: > On May 11, 2014, at 6:49 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >> >> Specifically, what I would recommend is: >> >> 1. Remove any references to the global flag from other documentation and error messages - always recommend the use of per-package flags to enable external downloads. >> 2. Deprecate the global flag in 1.6 >> 3. Remove it in 1.7 unless there is a marked increase in the proportion of verifiable vs unverifiable external hosting on PyPI. >> >> Adding a more explicit alias in step 2 would also be reasonable (since the meaning of the base "allow external" will be changing). Either way, the docs for the global option should acquire a caveat: >> >> "Note: The vast majority of links from PyPI to externally hosted packages are missing the hash information needed for verification, so this option won't actually allow downloading of most externally hosted packages - to handle such cases, use "allow-external" with the specific package name" >> >> Cheers, >> Nick. > > So, this is essentially my current PR except instead of removing the > --allow-all-external flag in 1.6 it's deprecated and removed in 1.7. I was on > the fence about removing vs deprecating the --allow-all-external flag. The only > reason I chose to remove it was I didn't feel very good about making it match > the semantics of --allow-external (external safe and unsafe) but the naming of > it made it sound like it was just the global option. > > I'm not completely against that. I think it's choosing between three bad > options, removing --allow-all-external, making it not match --allow-external, > or making it a global do an unsafe thing flag.
Yeah, "deprecated & not matching the per package semantics" is my suggestion at this point - you've persuaded me that dropping it is the right thing to do, so we're only discussing timing. > However before I go further on that I want to dig more into the impact of these > things. It dawned on me earlier today that the way I was categorizing things > in my earlier number crunching was making it unreasonably hard to actually > divine any sort of meaning out of those numbers. I'm currently in the process > of crawling all of PyPI again*, after I have those new numbers I'll have a > better sense of things and I think a better forward plan can be made. Cool. Cheers, Nick.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
