[Distutils] Role of distutils.cfg
ralf.gommers at gmail.com
Fri Nov 11 02:58:05 EST 2016
On Fri, Nov 11, 2016 at 12:27 AM, Christoph Groth <christoph at grothesque.org>
> I have a question on how to best handle parameters to the distribution
> given that they can be shadowed by the global configuration file,
> Our project 
You forgot to add all your links.
> contains C-extensions that include NumPy’s headers. To this end, our
> setup.py  sets the include_dirs parameter of setup() to NumPy’s include
> path. We have chosen this way, since it allows to add a common include
> path to all the extensions in one go. One advantage of this approach is
> that when the include_dirs parameters of the individual extensions are
> reconfigured (for example with a build configuration file), this does not
> interfere with the numpy include path.
> This has been working well for most of other users, but recently we got a
> bug report by someone for whom it doesn’t. It turns out that his system
> has a distutils.cfg that precedes over the include_dirs parameter to
> setup() .
> My question is now: is there a policy on the correct use of
> distutils.cfg? After all, it can override any parameter to any distutils
> command. As such, is passing options like include_dirs to setup() a bad
> idea in the first place, or should rather the use of distutils.cfg be
> reserved to cases like choosing an alternative compiler?
I'm not aware of any policy, but in general I'd recommend to pass as little
to setup() as possible.
Most robust is to only pass metadata (name, maintainer, url,
install_requires, etc.). In a number of cases you're forced to pass
ext_modules or cmdclass, which usually works fine. Passing individual
paths, compiler flags, etc. sounds unhealthy.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG