[Distutils] People want CPAN :-)

[Tarek Ziadé]

On Sun, Nov 8, 2009 at 2:22 PM, David Cournapeau <david at ar.media.kyoto-u.ac.jp>
[..]
>  - if you extend an existing command, you have to take care whether you run
>   under setuptools or distutils (and soon distribute will make this worse).

No, because unlike setuptools, we want to remove the patching that is done on
the Command class and on the DIstribution class, and make Distribute a good
Distutils citizen in that matter.

IOW you won't suffer anymore from what you've described.

>   Those commands will not work the same when you run them under paver
> either.
>  - the division in subcommands is painful, and the abstraction does not make
>   much sense IMHO. Recently, I needed to access simple things like library
>   filename (foo ->libfoo.a/foo.lib/etc..), install prefix. But those
> are not
>   accessible to each command.
[...]
>  - if you want to add a new source file extension, you have to rewrite the
>   build_ext or build_src command and  you often cannot reuse the base class
>   methods.
>  - etc...

This is going to be changed because I am currently refactoring the
build_ext command
so such methods are in a base "compiler" class and eventually in util.py

You are welcome to help in this refactoring,

> Also, the distutils code is horrible: you don't really know what's
> public and
> what's not, most attributes are added at runtime (and sometimes differ
> depending on the platform).
> Often, you get strange errors with the exception
> swallowed, and that happens only on some platforms for some users; in that
> case, the only way to debug it is to be able to run their platform. When you
> write extensions to distutils, this contributes to the whole unpleasant
> experience.

I agree the code is not modern, but things are getting changed through
small steps.

Although, I don't buy the "strange errors" part and things getting swallowed :)

[..]
>
> Guido wanted to know how scientific python people feel about the whole
> situation, and my own impression is that we are going further from what we
> need. I don't think anything based on distutils can help us. This is not to
> criticize Tarek, PJE and other people's work: I understand that
> distutils and
> setuptools solve a lot of problems for many people, and I may just be a
> minority.

My opinion is that you've build something else when Distutils was not
evolving anymore. This is not true anymore. It's moving again. And I
think that the work that is going on is heading in the right
direction, even for your use cases imho.

If projects that maintain distutils patched versions push those
patches now in the Python issue tracker, diffing against the current
trunk, and if those patches make sense and are with tests, that's by
far the *easiest* way to help improving Distutils.

And that's the easiest work for me : I'll just review them and commit
them if they do improve Distutils.

Tarek