On Thu, Feb 28, 2013 at 6:27 AM, Donald Stufft <donald.stu...@gmail.com> wrote: > Sometimes you need to break things. The goal is to do it with ample > warning and migration time so that people have a chance to move > to the new way of doing things. > > Again, I am not suggesting we delete all external links immediately, just > disable new ones. Removing old ones will come later.
This thread is long enough that I'm not sure on where to weigh in. Here seems appropriate enough. 1. The next generation metadata infrastructure will NOT support external hosting of files indexed on PyPI - if you don't upload the archive files to PyPI, they won't be included in the next generation metadata. If you want external hosting, you will need to run a separate index (this is similar to the yum model - you can host files wherever you want, but you need to run "yum createrepo" yourself to generate the metadata, and instruct users on how to get their installers to retrieve your metadata. The big difference between PyPI and the yum model is that the default index still won't be curated at all, so there's no review process to get through if you want to use it, thus less need for external hosting). 2. Near term, with the current generation infrastructure, I think it's better to approach the problem *very* gently. Our political capital with users is low at this point, and we need to prioritise what things we want to make people angry about (whether or not we consider their anger justified is completely irrelevant). This proposal is for a transition that would take months. Since I want to have the next generation metadata up and running within months *anyway*, that means this strikes me as primarily a distraction from fixing the problem properly. 3. Various other problems raised in this thread will only be fixed with next generation metadata that the automated tools can *rely* on rather than having to guess the intended semantics. That's why PEP 426 is now explicit about pre-release handling, and why it makes version specifiers like (for example), "Requires-Python: 2.6" exclude Python 3 by default. (although the thread does raise an interesting question of whether or not you can cleanly specify dual Python 2 & 3 support given the current state of PEP 426) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
