Switching python-setuptools to distribute

2009-10-12 Thread Toshio Kuratomi
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


pgpJ88btQCFCr.pgp
Description: PGP signature
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Switching python-setuptools to distribute

2009-10-12 Thread Konstantin Ryabitsev
2009/10/12 Toshio Kuratomi :
> 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.

FWIW, as a former maintainer of the package, I'm all for the switch to
distribute.

Cheers,
-- 
Konstantin Ryabitsev
Montréal, Québec

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


Re: Switching python-setuptools to distribute

2009-10-12 Thread Rahul Sundaram
On 10/12/2009 11:42 PM, Toshio Kuratomi wrote:

> 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 

You might want to post to distributions mailing list @ fd.o and get
other distributions feedback as well.

Rahul

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


Re: Switching python-setuptools to distribute

2009-10-13 Thread Mat Booth
2009/10/12 Toshio Kuratomi :
> 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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


Re: Switching python-setuptools to distribute

2009-10-13 Thread Toshio Kuratomi
On Tue, Oct 13, 2009 at 12:52:30PM +0100, Mat Booth wrote:
> 
> 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...
> 
He doesn't trust any of the people who want to work on it to touch his code.
He has made two or three other people committers but they lack either time
or interest in working on it.  In my personal interactions with him, he's a
control freak who wants to personally vette all the changes that go in.

This fork has been years in the making but if you want to see that yourself,
you'll need to read the python-dev archives for the past few months and
distutils-sig archives for the past few years.

-Toshio


pgpEbsLjOGYjy.pgp
Description: PGP signature
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Switching python-setuptools to distribute

2009-10-13 Thread GEORGIOS GIANNAKIS
2009/10/13, Mat Booth :
> 2009/10/12 Toshio Kuratomi :
>> 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@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


Re: Switching python-setuptools to distribute

2009-10-13 Thread GEORGIOS GIANNAKIS
WHO IS CORSEPIU?

2009/10/13, GEORGIOS GIANNAKIS :
> 2009/10/13, Mat Booth :
>> 2009/10/12 Toshio Kuratomi :
>>> 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@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


Re: Switching python-setuptools to distribute

2009-10-13 Thread GEORGIOS GIANNAKIS
2009/10/13, GEORGIOS GIANNAKIS :
> WHO IS CORSEPIU?
>
> 2009/10/13, GEORGIOS GIANNAKIS :
>> 2009/10/13, Mat Booth :
>>> 2009/10/12 Toshio Kuratomi :
 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@redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>>
>>
>

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list