2009/6/9 Eric Smith :

...

2009/6/8 Tarek Ziadé :

< plans and reasons to drop some commands from distutils, which I agree with >

...

...

- 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.

I don't think we need a policy at all. If no one wants to support it, it gets dropped. You can't tell volunteers what they have to do.

No, it could be kept in the stdlib as is. If no-one wants to do the work to handle the proposed change (from in the stdlib to externally supported) then why not keep the status quo? You seem to be saying that the correct approach should be to spend effort removing bdist_wininst and others from the stdlib regardless of whether someone is willing to commit to maintaining them externally. I'm saying that unless someone wants to take on the job of being an external maintainer, we should do nothing. If bdist_wininst gets a special exception and is kept in the stdlib, I'll shut up - I have no vested interest in any of the other bdist forms. Otherwise, I fail to see the point of this purge - bdist_wininst is important to Windows users, and I think it's important that it stays in the stdlib. To provide some concrete facts, here's the top of hg log for bdist_wininst.py: changeset: 39428:a8950f06efc1 branch: trunk user: mark.hammond date: Wed May 28 03:54:55 2008 +0200 summary: [svn r63755] bdist_wininst now works correctly when both --skip-build and --plat-name are specified. changeset: 39004:f56b6234cf8d branch: trunk user: mark.hammond date: Fri May 02 14:48:15 2008 +0200 summary: [svn r62636] #2581: Vista UAC/elevation support for bdist_wininst changeset: 38807:15196e08f04a branch: trunk user: mark.hammond date: Mon Apr 07 03:53:39 2008 +0200 summary: [svn r62197] Issue #2513: enable 64bit cross compilation on windows. changeset: 37535:1cd6136356e0 branch: trunk user: christian.heimes date: Mon Dec 31 15:47:07 2007 +0100 summary: [svn r59620] Added wininst-9.0.exe executable for VS 2008 changeset: 31774:201bf25423b8 branch: trunk user: loewis date: Wed Mar 23 19:54:36 2005 +0100 summary: [svn r38697] Make dist_files a triple, with the Python target version included, changeset: 31770:924c8e8c201a branch: trunk user: loewis date: Tue Mar 22 23:23:29 2005 +0100 summary: [svn r38692] Fix registration of output file. changeset: 31762:b47b4a1ac59c branch: trunk user: loewis date: Mon Mar 21 21:56:35 2005 +0100 summary: [svn r38684] Add the upload command. Make all dist commands register their Doesn't look like a huge burden - since 2005, there have been 7 changes - 3 contributed by Mark Hammond, 3 by Martin von Loewis, and one by Christian Heimes. All of whom I would assume would continue to provide such changes if bdist_wininst stays in the stdlib, but who may well not if it becomes externally maintained. Note: If I seem to be making a lot of fuss about bdist_wininst, that's because the only bdist modules in the stdlib right now are bdist_msi, bdist_wininst, bdist_rpm and bdist_dumb. Either this policy is aimed to a substantial extent at Windows, or it should be stated as "remove bdist_rpm from the stdlib". Can someone clearly articulate what is proposed here? I can see 4 main options: 1. Remove all 4 bdist modules (wininst, msi, rpm, dumb) from the stdlib, and let them be picked up by external maintainers, or die. 2. Remove bdist_rpm from the stdlib, so that RPMs don't have special status out of the Linux packaging formats, but retain bdist_msi, bdist_wininst and bdist_dumb (effectively, the "windows is a special exception" option). 3. Solicit offers from the community to maintain the 4 bdist_xxx modules as external packages on PyPI. If no such offers are forthcoming, continue as at present. 4. Simply make a formal policy that no new bdist_ commands will be implemented in the stdlib, and leave open the possibility that someone comes along and offers to pull one or more of the existing commands out into an external module on PyPI (hardly any different from the current status quo, except in being articulated a bit more explicitly). The only one which seriously concerns me is (1) out of the above. If someone (Tarek?) comes out and says that (1) is not what is being proposed, I'm happy to let the rest of the discussions take their course. Paul. PS I have a paranoid feeling that there's a subtext somewhere here to the effect that participants in the discussion don't see why there's such a big deal, as everyone should be using setuptools/easy_install/eggs anyway. Please let's avoid getting into that here. Can we assume for the purposes of this discussion that easy_install and eggs are not relevant, as the target audience for the bdist_ commands is *precisely* those people who don't want to use setuptools?