[Catalog-sig] Deprecate External Links

Noah Kantrowitz noah at coderanger.net
Wed Feb 27 19:11:09 CET 2013


On Feb 27, 2013, at 9:28 AM, M.-A. Lemburg wrote:

> On 27.02.2013 18:05, Noah Kantrowitz wrote:
>> 
>> 
>> "M.-A. Lemburg" <mal at egenix.com> wrote:
>>>> I propose we deprecate the external links that PyPI has published
>>>> on the /simple/ indexes which exist because of the history of PyPI.
>>>> Ideally in some number of months (1? 2?) we would turn off adding
>>>> these links from new releases, leaving the existing ones intact and
>>>> then a few months later the existing links be removed completely.
>>> 
>>> -1.
>>> 
>>> There are many reasons for not hosting packages and distributions
>>> on PyPI itself.
>>> 
>> 
>> [citation needed]
> 
> We've been through this discussion a couple of times in the past.
> I'm sure the reasons will get listed again in this discussion :-)
> 
> Too many distribution files for PyPI to handle,

Again, please point at a specific package. I wasn't aware that PyPI limited uploads at all, but if it does we can certainly increase the number if there is a good reason.

> no support for
> UCS2/UCS4 binary distributions, unsupported distribution file
> formats (e.g. our prebuilt format),

Not sure why PyPI would even care what charset the package files use, but if true thats certainly a bug and we can get that fixed. What file formats do pip/buildout support that PyPI doesn't support for uploads?

> giving up control
> are some of them.

This is the point of running a package server, the author gives up control over distribution in order to reap the benefits of solid infrastructure and discoverability. This is a feature.

> 
>> The legal restrictions on code on pypi itself is nothing more than needed to let people actually install things, which is kind of the point of listing on pypi. If someone really wants their own universe, run a package server yourself. What other reasons are there? Agreeing to an extra license would block pip anyway, so no loss there. Huge package files maybe? 
> 
> That's not quite true:
> 
> http://www.python.org/about/legal/
> 
> """
> ... third party content providers grant the PSF and all other users of the web site an irrevocable,
> worldwide, royalty-free, nonexclusive license to reproduce, distribute, transmit, display, perform,
> and publish such content, including in digital form.
> """
> 
> Once you upload the files to PyPI, you completely give up control,
> because that license is irrevocable. This goes far beyond what the
> Python license does:
> 
> http://docs.python.org/2/license.html
> 
> Changing the PyPI terms to be more author-friendly is on my agenda,
> but I haven't found the time for that particular discussion yet ;-)

You are comparing an artifact distribution requirement with a source code license. PyPI's terms don't say a thing about source code or anything else, just that if you want a package file to be installable, we need to be able to send it to people. There is nothing even remotely author unfriendly here, it is just common sense. Again, PyPI is _not_ the only way to publish packages, we are allowed to expect interoperability from people that choose to participate in our community.

--Noah

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130227/4bc6017b/attachment-0001.pgp>


More information about the Catalog-SIG mailing list