[Catalog-sig] [Proposal] Registered packages must provide the source code distribution on PyPI

[Andreas Jung]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

M.-A. Lemburg wrote:
> Andreas Jung wrote:
>> M.-A. Lemburg wrote:
>>> Andreas Jung wrote:
>>>> Hi there,
>>>>
>>>> I propose a policy change for packages registered with PyPI:
>>>>
>>>>  - packages registered on PyPI have at least one release
>>> I'm not sure what you mean with "release". Every package on
>>> PyPI is a release, since it comes with a version number.
>> This is a package without a release:
>>
>> http://pypi.python.org/pypi/python-openid
> 
> It has a name and a version number, so it's a release. It may
> be an unavailable release, just like say, Windows 98, is not
> available anymore - and that didn't have a source release
> file to download either :-)

I don't care if it has a name and a version number. I was not able
to work on my project - other co-workers also complained...this
is a not acceptable situation...as Python geek I can likely deal with
that, others can't :)

> 
> And I can see that you've added a comment to the package
> that the download URL is not working - that's good, since
> it will warn users to double-check.
> 
>>>>  - one release of registered package on PyPI _must_ contain
>>>>    a valid source code distribution (sdist)
>>> -100
>>> You'd outrule commercial packages that don't come with a
>>> source distribution. PyPI is for everyone, not only for
>>> open source packages.
>> Commercial package are a special case - I agree. The majority
>> of all PyPI are non-commercial. In addition you could also
>> upload binary release in addition to your own download server.
> 
> See my other comments: we might want to do that in the future,
> but at the moment, uploading 50 release files with around
> 150MB every time we do a release is not within range.

Point taken - but as said: your case is likely different.
When we do releases in the Zope world we also have to deal with lots
of packages...so doable somehow :)



>>> Furthermore, not all package authors want to upload their
>>> packages to PyPI.
>> And this is _exactly_ the problem. If you are a package author
>> and want to make your packages available to the public through PyPI,
>> you should be obligated for publishing the related distribution
>> files on PyPI: for the sake of availability and in order for being
>> independent of your own infrastructure. Otherwise I have the (arrogant)
>> opinion: go away - if you are a package author and want to use PyPI:
>> ensure that your software is available to everyone at any time.
> 
> What about those package authors who host their package
> elsewhere for various reasons and *do* make sure that their
> infrastructure is available - even if PyPI is down ?
> 
> I have the feeling that you had a problem with that one
> package you mentioned and the proposal was just a reaction
> to the associated anger with that.
> 
> It's not fair to start policing all packages on PyPI just
> because of that one incident you had.

We had such issues over and over again over the last years.
A typical Zope/Plone installation requires over hundred different
packages and we have seen such failures with external servers
various times. The workaround was creating PyPI mirrors, project related
mirrors or download caches....just workarounds but not really a reliable
and working infrastructure..

Andreas


- -- 
ZOPYX Limited           | zopyx group
Charlottenstr. 37/1     | The full-service network for Zope & Plone
D-72070 Tübingen        | Produce & Publish
www.zopyx.com           | www.produce-and-publish.com
- ------------------------------------------------------------------------
E-Publishing, Python, Zope & Plone development, Consulting


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwZ328ACgkQCJIWIbr9KYxyrACdESkhtKnlZmyBFc6SMnuY+1an
E70AoKrzyzcrCsLMrftXKAfz9UPtbcD5
=QFQd
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lists.vcf
Type: text/x-vcard
Size: 316 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20100617/0f5a925e/attachment-0001.vcf>