[Catalog-sig] Deprecate External Links

Doug Hellmann doug.hellmann at gmail.com
Thu Feb 28 17:29:06 CET 2013


On Feb 28, 2013, at 3:43 AM, Nick Coghlan wrote:

> On Thu, Feb 28, 2013 at 6:12 PM, M.-A. Lemburg <mal at egenix.com> 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   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig



More information about the Catalog-SIG mailing list