On May 15, 2014, at 5:12 AM, M.-A. Lemburg <m...@egenix.com> wrote: > On 15.05.2014 01:03, Nick Coghlan wrote: >> On 15 May 2014 01:07, "Donald Stufft" <don...@stufft.io> wrote: >>> >>> I’ve just published a draft of PEP 470 - Using Multi Index Support for >> External to PyPI Package File Hosting >>> >>> You can see this online at http://legacy.python.org/dev/peps/pep-0470/ or >> read below >>> >> >> For the record: I reviewed Donald's initial draft of this PEP and did some >> light copy editing when adding it to the PEPs repo, so this PEP can be >> taken as reflecting my perspective as well. >> >> Of the two currently implemented external hosting mechanisms, the "multiple >> indexes" model is more general, more explicit, easier to implement, much >> easier to explain and has much cleaner failure modes than the link >> spidering mechanism. The only missing piece is automated external index >> discovery, so adding that is included as part of this PEP. That federated >> discovery mechanism then clears the way for eventually dropping the link >> spidering mechanism (and all its associated complexity and complications) >> entirely. > > +1 on the general idea. I do have some issue with some aspects of > the PEP and will respond in more detail in a separate email.
Awesome! > > With regard to the index discovery, I'd like to suggest that we > use the existing download_url for this - along the lines I had > suggested last year and what eGenix is already using for such > index pages already (we switched to it as proof of concept > last year). My biggest concern with using download_url would be the fact that we have a lot of data there which is either wrong or out of date. It might work successfully, I’d need to do some comparison to see what that looks like. It might actually work out nicely though, it’s one of the URLs that pip/setuptools/etc will already scan prior to PEP 438 so there is a good chance that one of the ~7% of projects which are affected by this change will “work” automatically with the new system. It would be using —find-links instead of —extra-index-url but that isn’t a bad thing or wrong, just different. Setting up a —find-links target is slightly easier than setting up an —extra-index target. Not by a whole lot but it can essentially be either a direct link *to* a file, or to a page that contains links directly to a file. Projects wouldn’t have to worry about the /, /<project>/, /<project>/<version>/ url structure that the simple installer API supports. > > I'll work out a proposal and send it here later this week. Awesome, I look forward to seeing it. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
