(This post is a work in progress, as things still evolve)
In a way, I am glad I have made a fork, and I am glad this is going to
be the shortest fork ever. A lot of people reacted on my proposal and I
could get a very clear picture of what is wrong in the
distutils/setuptools world, and how I could help on this.
This is how I interpret it:
Guido explained that the mistake made was not to integrate setuptools
in the core from the very begining. The current distutils code did not
evolve in the meantime and Phillip Eby worked on setuptools to make it
evolve. setuptools now reaches a point where it needs other contributors
to fit all the needs and solve more problems. It had one contributor in
the past, (Jim Fulton) but it needs more. It also became a mandatory
package for many folks in the Python world because Phillip did a great
work on it : it solves most problems.
From what I could see, all the people that gets frustrated at some
point with setuptools, either don't use it, either try to see how it
could be changed. But when they try that, they take the same paths
others have taken before because there is a lack of info and
documentation on setuptools current status and future. And these paths
are quite long for the brain before you are able to provide a
well-thaught idea or patch.
I have tried to help myself on setuptools, then I have started to blame
Phillip saying that he did not have enough time to make setuptools
evolve. But that was the wrong approach, because the only problem
really, is a lack of visibility in setuptools development. And this is
something that can be fixed quite easily I believe. The bug tracker
added some months ago helped a lot. A roadmap and one or two page around
it and that should be it.
Guido also stated that it was merely impossible to work on the next
generation of distutils outside Python core. But in the meantime this
means that we need some people from the core to help us in there. And
they are really busy (I can understand that) on other matters in Python
code. We can write patches for some fixes for sure, and there are
hundreds of them to do in distutils.
But to boost it we would need a core developer that gives some love to
that package. I mean, for example I still have a patch waiting for
reviewing, wich only adds some unit tests that are lacking. There is
no code there, just unit tests, and it is pending since 6 months...
Guido said that I could try to become a core developer, that this was
not impossible, if I started to contribute patches often to other parts
of Python as well. But that's quite a challenge.
What frustrated me is that some people like Jim Fulton said they were
willing to work on a new distutils from scratch, and in the meantime I
understand what Guido says. he pointed us to Joel entry on rewriting
I don't have the brain to drive a fork of setuptools at this time. I
knew it from the beginning, I just wanted to make people react. I think
that setuptools can be the laboratory where we can experiment things,
and distutils the place where we can apply them at some point, with
Phillip help because he has a pretty big overview of all that. It is
going to take years, but well, we are young.
To help on this I will:
- try to gather people at the PloneConf to talk about it, maybe even sprint - try to document setuptools and distutils at my level, and write a roadmap for people to know what is going on. Either through a Sphinx site either on Python.org wiki. - work on patches for distutils, and try to point things in setuptools that might be brought into distutils - try to see if I have the brain to understand and work on other parts of Python.