> 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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
