[Distutils] People want CPAN

[Tarek Ziadé]

On Wed, Nov 11, 2009 at 1:31 PM, David Cournapeau <cournape at gmail.com> wrote:
[..]
> AFAIK, there is only one way to get the information: since the --prefix is only
> known once install.finalize_options() has run, you need to call the method from
> build_clib.
>
> Naive code could be something like
>
> class MyBuildClib(build_clib):
>    def run(self):
>        install_cmd = self.distribution.get_command_obj("install")
>        if not install_cmd.finalized == 1:
>            install_cmd.finalize_options()
>
>        if self.inplace == 1:
>            top = "."
>        else:
>            top = install_cmd.install_libbase
>        # top is the top directory where libraries should be installed
>        build_clib.run(self)
>
> It is already quite ugly, but it looks like it could work. It actually does in
> the simple case, like python setup.py install. But if you call python setup.py
> build_clib install --prefix=something, it does not. The error message is a
> typical example of distutils style: "error: must supply either prefix/exec-
> prefix/home or install-base/install-platbase -- not both". The only way I
> managed to make this work is to replace:

Ouch, That's not to be done. Something is wrong with your build_clib
design here.
You are roughly calling "install" as a sub command.

If you want to have install options for your command, and if your
command is about "installing",
it means that your command has to be a subcommand of "install". Those
get called once the options
passed to install have been finalized.

IOW, build_clib is not a subcommand of install, so you have troubles.

subcommands are: install_lib, install_headers, install_scripts,
install_data, install_egg_info
(and I agree that it's not simple to extend this list)

But, why in the first place, do you need the install --prefix in a
build command ?

For build_clib, if you need to build something, it goes in the
build_dir, or in place., and this is not impacted
by the install command.

>
> If you have a configure / build / install like the vast majority of build
> systems out there, this problem disappears. I don't see how the problem can be
> fixed without touching how commands work.

I fail to understand your demonstration. Commands that are in charge
of the *build*
have nothing to do with commands that are in charge of *installing*
file in various places
in the target system. So I fail to understand why build_clib interacts
with install,
and why it has to impact it howsoever (or vice-versa)

Now, if we take the generic use case (even if I don't think it should
be used in your case):

"a simple way to share options amongst commands"

As a matter of fact, there's a hackish way to perform this, by using
the distribution instance
as a placeholder for these "common" options, so several command can
read/write it.
(as opposed to local options and global options) without having to get
the command that manage the option.

But, at the end, since an option is either global, either specific to
a command, I guess a simple API in the command class should be enough
to avoid this hack:

   get_option(command_name, option_name)

This is similar to getting the command, (instanciate it + finalize it
if it doesn't exists yet)
and return a finalized option.

>
> Moreover, that's a typical example where the only way to be robust is to check
> that every attribute you are using actually exist before. At that point, you
> really want to run back to m4, perl, autogenerated makefiles and shell
> programming :)
>
>> I am still waiting for you comment on the solution to remove the
>> compile code from build_ext
>> and have it at the Extension level, with an option to add new
>> compilers in a  more easier way.
>
> I will try to document how scons does it. I think the basic idea could be
> reused in distutils.

But, you didn't answer: if we add the ability to define a different
compiler for each Extension,
will it solve your use case ?

>> If there's someone from the Numpy project that can help in isolating patches
>> againts Distutils trunk in our issue tracker, I'd be more than happy
>> to reduce the gap between
>> the two projects.
>
> If that was not clear, I am that guy. I have been the main
> maintainer of numpy.distutils and of numpy/scipy build infrastructure for some
> time now,

If you are willing to spend some time in that, I am the guy who can
commit your patches in Python.

Regards
Tarek