[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