[Distutils] distutils extension commands and option passing

Stefan Seefeld seefeld at sympatico.ca
Sat Sep 20 12:16:12 EDT 2003

Hi Thomas,

thanks for the reply. It's really a pitty that these things are
not documented...

Thomas Heller wrote:

> There are three ways that I know of:
> On the command line (undocumented, AFAIK):
>     python setup.py build_ext <build_ext options> bdist_rpm <bdst_rpm options>

interesting ! However, this doesn't really work in my case since the bdist_rpm
command generates a script that is calling 'python setup.py install', so the above
options aren't passed (i.e. the problem is that bdist_rpm would need a way to
'pass through' stuff without interpretation.

> In the setup.cfg file (documented):
> [build_ext]
> opt_1 = value_1
> opt_2 = value_2
> [bdist_rpm]
> opt_A = value_A
> opt_B = value_B

good, however, this would apply to every build then, right ? What I was
looking for was a way to call 'python setup.py bdist_rpm --foo' and
'python setup.py bdist_rpm --bar' and have both build *different* rpms.
And that is hard to achieve as bdist_rpm only has a fixed set of params
and extending it is very hard.

> And finally, you can pass a nested dictionary of options to the setup
> script (aldo undocumented, AFAIK):
> options = {"build_exe": {"opt1": "value1", "opt2": "value2"}
>            "bdist_rpm": {"opta": "valuea", "optb": "valueb"}}

hmm, that looks best, but it requires some top-level parameter processing
to yield the flexibility I desire, i.e. before calling setup() I'd have
to process the parameters myself and then fill these dictionaries appropriately.

Looking into the code I see how the default commands do what I want:

snippet from bdist_rpm:

         sdist = self.reinitialize_command('sdist')
         if self.use_bzip2:
             sdist.formats = ['bztar']
             sdist.formats = ['gztar']

i.e. commands can communicate among each other through the
'distribution' object. Of course, that's quite fragile as it
requires these commands to know each other, so setting or modifying
another command's option 'in memory' has to be done with care.

> IMO, patches for the docs would be appreciated.

Hmm, is *anybody* actively working on distutils ? Of course,
documenting existing code / practice would be a good start.
But at some point I'd like to provide patches that enhance
distutils, but for that I'd prefer to have a clear idea of
the mental model the developers have (had ?) when working out
the framework.

There are notably two places I think would be worth enhancing:

* a much enhanced 'config' command that provides functions to test
platform specifics, similar to autoconf.

* a much more flexible (and extensible !) way to deal with


More information about the Distutils-SIG mailing list