On Feb 28, 2013, at 3:43 AM, Nick Coghlan wrote: > On Thu, Feb 28, 2013 at 6:12 PM, M.-A. Lemburg <[email protected]> wrote: >> On 28.02.2013 07:39, Nick Coghlan wrote: >>> 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). >> >> Could you elaborate on this ? >> >> AFAIK, the metadata only works on package names, regardless of where >> an installer finds them. > > Caveat: this is NOT a final design, and people that aren't me will be > working out the exact details. It is, however, how I want it to work. > > The next generation metadata publication infrastructure is likely to > be based on TUF, and thus will consist of pregenerated, signed > metadata served as static files. Installers will just download > metadata files, sdists and wheels (and probably eggs and tar balls),
It sounds like that move will also be a good opportunity to create a reusable PyPI client library that the installer front-ends (easy_install, pip, whatever) could use, to provide some consistent behavior between the tools. I would like to see it *only* work with PyPI to upload, search, and download distributions but not create distributions, not find them anywhere else, and not upload them anywhere else. Doug > and never need to contact an active web service. The only "active" web > service technically required will be one to regularly refresh the > signed timestamp file that prevents certain kinds of attacks based on > providing old, insecure versions of software (a cron job running on > the server hosting the metadata would suffice for this task). PyPI > itself will have another active service to automatically regenerate > the metadata when files are uploaded by maintainers. The delegation of > trust within the framework will be defined only for files hosted by > PyPI - it will not be extended to allow the declaration of external > URLs as a source for the target files. > > Publishers will still be able to publish on external sites, but they > will need to generate their own metadata, and distributions published > that way won't be indexed in the next generation metadata on PyPI. > This is the same way yum repos work - the metadata for each repo only > covers SRPMs and RPMs hosted in that repo. If you want to download > software from somewhere else, you have to add another repo definition > in the client so it knows where to look for the metadata. APT works in > a similar fashion. > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia > _______________________________________________ > Catalog-SIG mailing list > [email protected] > http://mail.python.org/mailman/listinfo/catalog-sig _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
