[Distutils] What precisely is meant by removing bdist modules from the stdlib? (Was: Packaging: bdist_deb patches)

[Paul Moore]

2009/6/9 Eric Smith <eric at trueblade.com>:
>> 2009/6/8 Tarek Ziadé <ziade.tarek at gmail.com>:
>
> < 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?