[Distutils] Role of distutils.cfg

[Ralf Gommers]

On Fri, Nov 11, 2016 at 12:27 AM, Christoph Groth <christoph at grothesque.org>
wrote:

> Hi,
>
> I have a question on how to best handle parameters to the distribution
> given that they can be shadowed by the global configuration file,
> distutils.cfg.
>
> Our project [1]


You forgot to add all your links.


> contains C-extensions that include NumPy’s headers.  To this end, our
> setup.py [2] 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() [3].
>
> 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.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20161111/9e5a8241/attachment.html>