[Catalog-sig] [Proposal] Registered packages must provide the source code distribution on PyPI
mal at egenix.com
Thu Jun 17 10:28:25 CEST 2010
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:
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 :-)
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)
>> 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.
>> 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.
> PyPI is not a kindergarten - PyPI is an important resource for
> professional Python development. CPAN is better organized and more
> reliable for more than ten years than PyPI ever was.
To be fair, CPAN has been around a lot longer than PyPI.
Regarding reliability of PyPI: as you've probably seen, I'm
taking that seriously and want to enhance the reliability of PyPI.
Regarding PyPI being used as resource for professional development:
the zc.buildout approach has taken that idea a bit far, IMHO.
PyPI wasn't designed to be used by automated download and
installation tools that install hundreds of packages as opposed
to the few packages that users request manually via easy_install.
It's good to see, that PyPI can still cope with that approach
and pushing the data to the cloud and/or mirror servers will
enhance that performance even more.
Professional Python Services directly from the Source (#1, Jun 17 2010)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
2010-07-19: EuroPython 2010, Birmingham, UK 31 days to go
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
More information about the Catalog-SIG