On Jun 9, 2009, at 1:45 PM, Gerry Reno wrote:
Tarek, I understand your position on this. However, here is what needs considered if you want to split out this functionality. 'bdist_rpm' operates rather well and you can automate the generation of packages using this target. What I would hope not to see is that we end up with an entire fragmentation of different approaches to developing similar targets for other platforms such as targets like 'bdist_deb', 'bdist_mac', etc. Whatever group would be selected to take over this functionality should take over responsibility for all these targets and they be developed in a coordinated manner so that it would be easily understood by the user how to generated packages for multiple platforms using the targets and similar settings in setup.cfg and any auxiliary files similar to rpm_install_sh.txt. If a group can be selected to handle these all these targets with the above goals in mind then I think it would be possible to split this functionality out of the core. But, if the cannot be done, then I think this functionality should remain with the core in order to avoid fragmentation to the approaches in developing these 'bdist_xxx' targets.
What exactly you mean by all these? If I'm not mistaken only rpm, windows and a generic unixy binary packages exists in distutils today, and rpm packages are hardly close to a windows installer package (in terms of install scripts etc) so I don't see what you mean by they being the same now and your fear of they growing different.
Also I don't see how having a bit of code inside the stdlib is easier to maintain than code outside it. Seeing how long a patch takes to be applied in the stdlib and how no one can receive commit rights to work on just a submodule of it I think that working as an outside project is actually beneficial to all those projects in case something change on their package tool, and if nothing changes they can keep up pretty easily with distutils.
ps: Tarek is one of the exceptions right? He works only on distutils.
-- Leonardo Santagada santagada at gmail.com