[Catalog-sig] disallowing the removal of packages?

[Daniel Greenfeld]

Alright, my two cents:

1. I would love an eternal PyPI mirror. The only things that should go
away are things that violate the law or have grave security risks.

2. You can't expect anyone on the planet to build applications that
are robust enough to handle when a package or a particular release
suddenly vanishes. For example, if I'm building a Bluebream app and
zca.core goes away, then me and every other Zope developer is screwed.
Same goes for PyQT, Django, and the rest of the Python universe.

3. IMHO, the index is for package maintainers AND consumers.
Maintainers have a place that provides hosting and the ability to
track usage, and consumers have a place that provides searching and a
go-to place for install tools. If that wasn't the original intent
during the inception of PyPI, then maybe the intent ought to be
changed to match this new intention.

Daniel Greenfeld

On Tue, Jul 5, 2011 at 7:25 AM, Andreas Jung <lists at zopyx.com> wrote:
>
>
> Martijn Faassen wrote:
>>
>> Hi there,
>>
>> My development project relied on a certain version of a package that is
>> hosted on pypi. Unfortunately the package mainatainer had decided that
>> certain older versions of the package were not longer supported and had
>> removed them from PyPI altogether.
>>
>> This broke the build procedure for my project: I had carefully pinned
>> down that I wanted this version (as that's what we tested with), and it
>> wasn't available anymore.
>>
>> So, the removal of old packages from PyPI means that other people who
>> rely on these packages with their installation instructions ("install
>> Foo 3.3") or build tools (installation instructions, automated),
>> suddenly have to deal with breakage.
>>
>> I thought perhaps PyPI can help and handle this problem at the source.
>>
>> What are the possible use cases for removing a release from PyPI?
>>
>> a) mistakes: the upload was accidental - we weren't supposed to release
>> this at all! I.e. I uploaded private code that I never meant to
>> distribute in the first place.
>>
>> b) actively hostile: the upload actually contains deliberately malicious
>> code and protecting people against this *should* break their builds
>>
>> c) legal issues: some party claims that this code is not PyPI's to
>> distribute in the first place, and for legal issues it'd need to be
>> taken down.
>>
>> d) broken: security or other bugs that makes us want to loudly say, this
>> is so broken, don't use it anymore
>>
>> e) cleaning up old stale unsupported stuff.
>>
>> I'd argue d) and e) are not up to the package maintainer to decide but
>> to the person who integrates this package into their system. The person
>> who integrates the package is the one who will need to make the judgment
>> call to continue to use old unsupported or broken stuff. Integrators
>> should be allowed to make such decisions in their own time at their own
>> convenience; the package developer shouldn't be able to force such
>> decisions by removing an old release.
>>
>> (We can think about better warning mechanisms: perhaps there could be
>> some metadata or rule to decide when an old release is "deprecated" and
>> then integration and installation tools could warn about this, but all
>> this would be to help the integrator a better decision on what to do.)
>>
>> Use cases a), b) and c) are left. I think b) and c) should be handled by
>> the PyPI administrators: this takes a judgment call and the package
>> maintainer might not be involved in this at all.
>>
>> Use case a) is the tricky one. I could upload something by mistake, and
>> then immediately discover it and decide to throw it out again. But I'd
>> be fine if I weren't allowed removing a release anymore after a period
>> of a month. It could be that I only discover my mistake after a month,
>> when people have already started relying on this version, but in that
>> case as a PyPI user I'd want the administrators to issue a judgement
>> call there too.
>>
>> So, my proposal would be to allow people to remove a recent release
>> freely, but after a period of (I don't know? A day? A week? A month?)
>> removing the old release is not allowed anymore.
>
> First I have to second Martijn in all aspects (bascially because
> are coming from the same projects and facing similar problems).
>
> The main (meta) question is: is PyPI a the wild-west of the Python world
> where everyone can do with packages or do we want PyPI being a well-managed
> place for packages with a certain number of rules. Looking at the RSS feed
> each day makes me angry sometimes because PyPI feels like the dumpster of
> the Python world. The points Martijn raised are only one aspect of this
> question.
>
> -aj
>
>
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
>
>



-- 
'Knowledge is Power'
Daniel Greenfeld
http://pydanny.blogspot.com
http://cartwheelweb.com