The attached setup.py file defines a custom command named "test", which
is implemented in a class named "TestClass". Try to run both of the
following:

1) ./setup.py test -h
2) ./setup.py --help-commands

In case 1, Distutils will use the class name to print the help output.
In case 2, it will use the command name. This behaviour is inconsistent.
As a developer, if I want to get the output right in both cases, I am
forced to use the same name both for the command class and the command
name (a string in a dictionary).

I propose that Distutils always use the command name. Besides fixing the
inconsistency, this solution gives the freedom to choose class names
back to the developer.

I have tested this behaviour on Mac OS X 10.5, both with the
system-provided Python 2.5 and custom-installed versions of Python 2.6
and 3.1.

Right, thanks for noticing this.

Here's the change I am going to make:

The code will use command.get_command_name() *everywhere* for the help 
display.

This method implemented in Command does the following:

- if the attribute "command_name" is present, it is returned
- __class__.__name__ ortherwise.

Meaning that you can define the name you want in the class.

Notice that this is under-documented so I need to add some document
for that behavior/feature.

I will not push this change in 2.7 since I don't consider this as a 
bug.

To be able to do this fix, I also need to change the way commands are
registered in Distutils.

Right now, Distutils scans packages that were provided as "command
packages" and just adds all commands from the namespace, using the class
name. Which means there's no way to provide a command this way that is
not using something else than the class name.

To make it better I will introduce an explicit registration mecanism,
where a specific mapping will have to be provided in the package,
instead of looking directly for "pkgname.command", which is not very
handy from a developer point of view. (this behavior will be deprecated
but will still be used as the last way to register a command)

>To be able to do this fix, I also need to change the way commands are
>registered in Distutils.

Hm, I thought commands were registered in the setup() function with the
cmdclass dict. Like this:

setup(
      # "test" is the name that should be used for display
      cmdclass = { "test" : TestClass },
     )

And the dict key can then be used as the name to display. At least
"--help-commands" does it this way.


Please note that I don't want to criticize: I'm just a dumb user who
hasn't spent 5 seconds investigating how distutils works. I just
thought, maybe you have overlooked something and this could save you
some time...

Anyway, thanks for taking this on.

Patrick

It's a bit more complicated.

the option you are desrcibing it just one way to register commands in fact.

Distutils also has a discovery function that will load commands from
packages, and that's where the biggest issue is.

This is a murky area, I’m not sure we have to refactor so much just to fix this bug.  Maybe it’s a doc bug: People have to define command_name if their command has a name that is different from the class name.  Maybe it’s a simple fix in the code for -h.  I’d like us to try this way first.

Improving the command registration system can be a feature request in another bug report targeted at distutils2.