[SciPy-user] install location of the newcore header files

[Pearu Peterson]

On Tue, 11 Oct 2005, Gerard Vermeulen wrote:
>> Robert Kern wrote:
>>> To anybody who can't install some files in the "standard" locations, I advise
>>> to do something like:
>>>
>>> python setup.py install --root=~/MyPythonStuff
>>>
>>> The directory layout of this installation under ~/MyPythonStuff is the
>>> same as if it would be installed in the Python tree.
>>>
>>> It is a minor adjustment for the dictates of distutils; and works for
>>> any package which tries to install headers in the "standard" locations.
>>
>> I know about that. You're missing my point, however, that it then
>> requires one to modify the setup script of every *other* package that
>> needs the scipy header files to compile to point to this alternate,
>> nonstandard location.
>
> Why?
>
> (1) One can always add non-standard include directories:
>
> python setup.py build_ext --help
> ..
> --include-dirs (-I)  list of directories to search for header files
> ..
>    and this is a worst case.  I am pretty sure this can be taken
>    care of in a config file.

I have noticed that even experienced Python programmers hardly use
distutils commands with extra options or even know about distutils 
possibilities that could easily help to resolve various problems, they 
rather write emails to mailing lists.

> (2) If you recommend the 'install --root' method the location of the
>    alternative Python include directory is implicitly known and is
>    easy to figure out. I will use such a facility if SciPy offers it.
>
>> That interferes with automated building and
>> installation. It's also incompatible with PythonEggs because they can't
>> contain header files to be installed the old way.
>>
>
> I have refrained from commenting on PythonEggs, but I think it has a design
> problem if it can't handle standard distutils packages (how does PythonEggs
> handle C extension modules?).

I agree on that.

>>
>> It's a burden on the user rather than the developer. It's a cost that
>> gets paid every time he has to install something that needs the scipy
>> includes.
>
> You mean a minority of users (< 5 % ?) and you should not think in terms of
> SciPy only.  Isn't it better in the long run to educate those users so that
> they can cope with any distutils package that exports a C-API?

Where did you get this number? I think majority of potential users will
stop using a software if they need to learn such details.

>> Putting the headers into the package means that it will work
>> in every conceivable installation in exactly the same way everywhere
>> without effort on the part of the user.
>
> True; but the cost is that you are breaking a standard.

Is it then so bad if breaking the standard makes the life of users easier 
as well as of those who try to support users? And I don't see any harm in 
breaking this particular bit of the Python standard.

>> That's worth making developers
>> read the documentation (or the compile commands spat out by distutils)
>> to find the headers.
>
> I see myself recompiling SciPy (or any other package) when I want to find the
> headers. IMO the problem can be solved with 10 lines in a README (see point 2
> above) without putting a burden on developers.

Note that Scipy developers should use scipy.distutils anyway instead of 
standard distutils for various reasons, and when using scipy.distutils, 
the scipy include directory is added silently to the list of include 
directories and so Scipy developrs need not to worry about the current 
issue at all.

Pearu