[Distutils] The problem with Setuptools on Python 3.

[Antonio Cavallo]

> And, as I frequently run into walls that make me thing setuptools
> should be completely ignored, and then after fiddling about quite a
> bit, find a way around it, and then run into the next wall, etc, etc,
> etc. And these walls are getting more and more frequent... I'm
> beginning to think that indeed rewrites are the only way.
>
> We need a plan. Somebody please make a plan, maybe I can help. But
> probably not. But I can try.

I second that especially because I think setuptools looks like an over
engineering excercise: I have many doubts about about setuptools,
especially from a system administrative point of view.

Why a build system (and setup.py is) should have a scm support in it?
Why the plugin entry points should be part of such a system?
Why the dependecied should be part of it?

The scm support is part of a "development" stage, possibly useful to
the developers only: that'd be better covered by a python script not
tighted to the "building system".

The plugin entry points (belonging to a "deployment" stage) are a bit
of a problem because the paths might not be in their "final" form
(think of DESTDIR temporary staging area while building a rpm): this
mean the onlyreliable way to define entry points would be relative to
modulename.__file__ variable.

The dependencies part (belonging to a "deployment" stage) is a bit of
a system wide problem.
Rpm defines the same fields and then this introduce a (not so) hidden
duplication: will the package respect the python dependencies or the
rpm ones?

I would recomend having a look at what rpm (and especially the spec
files) does because it had embedded a lot of knoweledge about building
packages across the years: and it still has its own problems....

Moving forward, itwould be beneficial a flow chart of what distutils
should do (and shouldn't) and a possibly a usage cases study.
Regards,
Antonio