[Catalog-sig] PyPI terms (was: Deprecate External Links)
mal at egenix.com
Fri Mar 1 12:47:22 CET 2013
On 01.03.2013 12:30, Jesse Noller wrote:
> Marc Andre: I'm cc'ing Van: can you explain why the pypi terms are a bummer so we can see if there is actually an issue to be resolved or a matter of taste?
> We need to protect the foundation while preserving author rights - but I don't want one user / subset dictating how we evolve the technology.
I think we should move this discussion to the python-legal-sig list:
Let me know when you've subscribed and then we can hash things
out on that list. The catalog sig is not really the suitable
place for these discussions.
> On Mar 1, 2013, at 4:24 AM, "M.-A. Lemburg" <mal at egenix.com> wrote:
>> On 01.03.2013 10:02, Reinout van Rees wrote:
>>> On 28-02-13 21:08, holger krekel wrote:
>>>>> I have seen that position in this discussion ("I have to upload 120
>>>>>> files per release, so I won't do that", for instance).
>>>> haven't seen that.
>>> Marc-Andre Lemburg said this, which I took to mean 120 uploads per release:
>>> However, taking our egenix-mx-base package as example, we have
>>> 120 distribution files for every single release. Uploading those
>>> to PyPI would not only take long, but also ...
>> Correct, with a total of over 100MB per release. However, the above
>> quote is slightly incorrect: I did not say "I won't do that", just
>> that there are issues with doing this:
>> * It currently takes too long uploading that many files to
>> PyPI. This causes a problem, since in order to start the upload,
>> we have to register the release on PyPI, which tools will then
>> immediately find. However, during the upload time, they won't
>> necessarily find the right files to download and then fail.
>> The proposed pull mechanism (see
>> would work around this problem: tools would simply go to
>> our servers in case they can't find the files on PyPI.
>> * PyPI doesn't allow us to upload two egg files with the same
>> name: we have to provide egg files for UCS2 Python builds and
>> UCS4 Python builds, since easy_install/setuptools/pip don't
>> differentiate between the two variants. This is the main
>> reason why we're hosting our own PyPI-style indexes, one for
>> UCS2 and the other for UCS4 builds:
>> * I'm not sure whether we want to import our crypto packages
>> to the US, so for a subset of the files, we'd probably
>> continue to use our servers in Germany.
>> Again, with the above proposal, this shouldn't be a problem.
>> * Ihe PyPI terms are a bummer for us, but this can be fixed,
>> I guess.
>> If we can resolve the issues, we'd have no problem having the
>> files mirrored on PyPI.
>> Marc-Andre Lemburg
>> Professional Python Services directly from the Source (#1, Mar 01 2013)
>>>>> Python Projects, Consulting and Support ... http://www.egenix.com/
>>>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/
>>>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
>> ::::: Try our 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
>> Catalog-SIG mailing list
>> Catalog-SIG at python.org
Professional Python Services directly from the Source (#1, Mar 01 2013)
>>> Python Projects, Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::::: Try our 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