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

M.-A. Lemburg mal at egenix.com
Thu Jun 17 19:21:45 CEST 2010


Andreas Jung wrote:
> M.-A. Lemburg wrote:
>> Andreas Jung wrote:
>>> Tres Seaver wrote:
>>>
>>>> Note however that Andreas' proposal was to require that 'sdists' be
>>>> uploaded.  I personally won't use binary-only packages, but it has
>>>> historically been true that PyPI was intended to support them, as well
>>>> as to support registration of packages hosted offsite.  Andreas'
>>>> proposal doesn't address either of those cases.
>>> A more precise requirement would be:
>>>
>>>  - upload the sdist if your package is open-source
>>>  - upload the official distribution package if you are package
>>>    is commercial
>>>
>>> Basically...upload everything that you would also keep on your own
>>> server as official distribution.
> 
>> We cannot force authors to do this. There may be other reasons
>> why they can't upload such things to PyPI, e.g. crypto, trademark
>> and copyright laws, or even corporate rules if the author is
>> maintaining the package as part of his or her job.
> 
> You are once again talking about edge cases. In general the majority of
> all externally hosted packages are not affected by such issues and
> should be hosted on PyPI.

Well, there's certainly some reason why the authors chose
not to host on PyPI. I can only list a few.

>> If more package authors start shipping egg files for
>> the various Unix platforms as both UCS2 and UCS4 and for 3 or
>> 4 different Python versions and keep those files around for
>> several releases, we'll run into problems with having
>> to mirror all those download files.
> 
> There is in general zero need for uploading eggs for various
> Python versions if the module is Python only. I have seen packages
> with upload for Python 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 3.0, 3.1 for
> Python-only packages. This is really nonsense...a single sdist
> is usally good enough...I bring it to the point: a bunch of Python
> developer have no idea about package hygiene and use PyPI as package toilet.

If you ship Python-only packages with precompiled .pyc/.pyo
files, you do need to upload one version per Python version.
The marshal format and pyc magic often changes between releases.

Some developers probably don't know that if they switch off
the pyc compilation step, they'd get a single .egg file for
all Python versions they support. In that case, we'd need
to educate them, not call them names.

If you want more people to upload and host their packages
on PyPI, you have to:

 * make PyPI itself more robust and stable (we're working on that)

 * improve the tools to make both uploads and downloads
   easier (perhaps you could help with this)

 * convince people that their code is in good hands on PyPI
   (we'd need to get the PyPI terms straightened to help with
   this part)

Suggesting that they can never remove a release from PyPI
or are not allowed to rename a package is not going to
attract more developers to PyPI.

Calling them names, suggesting that their software is crap
or that they use PyPI as dump, isn't going to attract
anyone either.

Anyway, I think I've said everything I wanted to say about
this.

-- 
Marc-Andre Lemburg
eGenix.com

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
               http://www.egenix.com/company/contact/


More information about the Catalog-SIG mailing list