Switching python-setuptools to distribute

[GEORGIOS GIANNAKIS]

2009/10/13, GEORGIOS GIANNAKIS <georgios.giannakis.stavros at gmail.com>:
> WHO IS CORSEPIU?
>
> 2009/10/13, GEORGIOS GIANNAKIS <georgios.giannakis.stavros at gmail.com>:
>> 2009/10/13, Mat Booth <fedora at matbooth.co.uk>:
>>> 2009/10/12 Toshio Kuratomi <a.badger at gmail.com>:
>>>> I've been a comaintainer of the python-setuptools package for a long
>>>> time
>>>> and recently became the owner when icon relinquished it.  It is
>>>> currently
>>>> a
>>>> tumultuous time for distributing python modules with a new and active
>>>> maintainer for distutils inside of the python stdlib and a fork of
>>>> setuptools being worked on.
>>>>
>>>> That fork is named distribute and there are two branches of development
>>>> on
>>>> it.  The 0.7 branch aims to implement API, metadata, and other features
>>>> that
>>>> will make packaging python modules for upstream building and
>>>> distribution
>>>> easier while being more concerned with the effects this has on
>>>> Linux packagers.  The 0.6 branch intends to be compatible with the
>>>> current
>>>> seutptools package but to fix bugs and introduce features that are
>>>> backwards
>>>> compatible and oft requested.  This branch is being actively maintained
>>>> by
>>>> a
>>>> core group of five committers including the new distutils maintainer.
>>>> By
>>>> contrast, setuptools is maintained by a single maintainer who often has
>>>> little time to work on it.
>>>>
>>>> When installed, the 0.6 branch takes over the setuptools and
>>>> pkg_resources
>>>> python modules.  The reasoning is that distribute-0.6 provides the same
>>>> API
>>>> as setuptools and is meant to replace it.  If the module was installed
>>>> differently, consuming code (all the setup.py modules in any setuptools
>>>> using package as well as code that relies on setuptools features at
>>>> runtime)
>>>> would all need to change their import statements to use the new names
>>>> explicitly.  This choice is being made upstream by the distribute
>>>> project.
>>>>
>>>> Upstream, the python community has viewed the fork favorably but since
>>>> it's
>>>> not part of python proper, the only one with say in the matter is the
>>>> setuptools author.  He has not been willing to abandon the setuptools
>>>> module
>>>> but at the same time hasn't gained any more free time to work on
>>>> setuptools.
>>>>
>>>> Several other Linux distributions (gentoo and arch) have started
>>>> shipping
>>>> distribute-0.6 as the source of their setuptools package.  I am
>>>> thinking
>>>> of
>>>> doing the same for rawhide and pushing the change to older Fedora
>>>> releases
>>>> if bugs are reported that are fixed in distribute but not in seutptools
>>>> as
>>>> having a responsive upstream that cares about distribution packaging
>>>> issues
>>>> is a great plus for us.  I raised this plan on fedora-python-devel and
>>>> received one positive comment and no negative feedback so I'm just
>>>> mentioning it here so a broader audience can ask any questions or raise
>>>> any
>>>> issues before putting this into effect.
>>>>
>>>> -Toshio
>>>>
>>>
>>> I was unaware of all this. Is there a reason why the setuptools author
>>> will not grant commit rights to others? Going solely on your email it
>>> seems like a fork would be unnecessary if he was willing to share the
>>> workload...
>>>
>>>
>>> --
>>> Mat Booth
>>>
>>> A: Because it destroys the order of the conversation.
>>> Q: Why shouldn't you do it?
>>> A: Posting your reply above the original message.
>>> Q: What is top-posting?
>>>
>>> --
>>> fedora-devel-list mailing list
>>> fedora-devel-list at redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>>
>>
>