[Catalog-sig] an immutable mirror of PyPI

Alan Franzoni mailing at franzoni.eu
Wed Jul 6 09:59:16 CEST 2011

On Tue, Jul 5, 2011 at 8:56 PM, Martijn Faassen <faassen at startifact.com> wrote:

I had some thoughts myself on the topic; I think the idea of an
immutable (or almost-immutable) pypi would be a rather good one.

If you've had some kind of experience with Maven repositories in the
Java world you know they're usually a good idea for dependency
management; then you can setup your own internal proxy/mirror which
you can rely on if some external server fades away.

Mirroring a mutable pypi is not as easy as it sounds: what do I do if
a release file is deleted and replaced with another file, same release
number? How should my mirror work?

Maven repos usually never allow for artifacts to be removed from their
interface - you should remove them at filesystem level, but then you
know you're doing something the system doesn't want you to.

Rubygems approach is different but still takes care of version
immutability a bit: you can yank a release, thus removing the
artifact, but you're prevented from reuploading anything for the same

The downside of mutability is:

- today, I've got a working project which fetches dependencies through
- the project stays the same, one year passes.
- The project no longer works because some deps on pypi changed or were removed.

There're of course some good use cases for package removal, but
they're "edgy": e.g. leaked credentials in source code, leaked
unauthorized code, etc.

OTOH there's the maintenance problem for package authors - I'd suggest
something like a way to deprecate packages and releases, so that when
anybody fetches such packages it can get a "deprecated" warning and
should know the author is not maintaining such code anymore, but won't
prevent legitimate and informed users to happily keep going with their
existing software.

Of course all of those things that I propose might just not fit into
PyPI. If anybody is interested in creating a PyRepo or something like
that, just let me know and I'd happily collaborate.

http://www.franzoni.eu - public@[mysurname].eu
Latest blog post: Unit testing with Twisted: testing protocols:

More information about the Catalog-SIG mailing list