2009/6/8 Tarek Ziadé email@example.com:
During the summit at Pycon, we have said that it would be a better strategy not to include within Distutils os-specific tools for various reasons (and also to remove existing ones) :
- it's better for them to have their own release cycles
I don't see why. The one I'm interested in (bdist_wininst) doesn't change often, and doesn't need a different release cycle (IMHO).
- it's hard for me, as distutils maintainer, to maintain and make
evolve os-specific tools. People that are specialists on those OS will do a better job.
Sorry, but while I appreciate your difficulty, that's not a good enough reason. The rest of Python core is maintained by people who don't have access to all OSes. Packages like subprocess and threading manage. Just take patches from interested community members - you act as a manager rather than a developer in those areas, but that's OK.
Now the problems to reach that goal are:
- some people are reluctant not to have everything included in the
stdlib (I am not). I don't think we can all agree on this, and since Guido have encouraged this strategy during the summit, I guess I'm more inclined to follow it nevertheless.
While "Guido says so" beats any other argument, I'd like to hear some good reasons - at least for bdist_wininst. For the Linux package formats, where there's a lot of interest in packaging and strong views on what's "right", I can see the point. For Windows, where nobody gets excited about it, moving bdist_wininst out of the core risks nobody caring enough to keep it going, and thus no packaging solution at all on Windows.
- we need to detect for each existing command (rpm, etc) a project
that can take over, prior to remove it from Distutils when appliable .
And a policy on what to do if no such project can be found.