Harald Meland writes:

Hi,

I'm trying to figure out how I can make distutils support installation of scripts to more than one directory, e.g. both <prefix>/bin/ and <prefix>/sbin/.

I've found an open bug[1] on this in the Python project on SourceForge, but it's now over a year since the person that bug is assigned to said that he would "look at this".

That would have been me. I've unassigned it from myself, which I guess isn't progress... but is realistic, I'm afraid.

I started by looking through the documentation, but could not find any info on how to extend distutils. Hence, I had a look at how distutils is currently implemented, but I'm still not sure how one is meant to *properly* extend the "install*" feature set.

I think that any way that works is more or less the proper way. The distutils are a thing of wonder, but the code isn't the easiest to understand in the world. Cheers, M. -- If trees could scream, would we be so cavalier about cutting them down? We might, if they screamed all the time, for no good reason. -- Jack Handey

Harald Meland wrote:

[Michael Hudson]

...

Harald Meland writes:

...

Hi,

I'm trying to figure out how I can make distutils support installation of scripts to more than one directory, e.g. both <prefix>/bin/ and <prefix>/sbin/.

Hmmm... I think I might be able to pull off something that will work with the code as it stands today. However, it will probably be rather fragile with respect to any changes done to any of the involved distutils commands (as my current plan is to have my extensions subclass these).

Subclassing is probably the right thing to do here. The easiest way to do this is by writing you own command and then let that command replace the standard install_scripts command.

However, I'm wondering if the functionality I'm after ought to be part of vanilla distutils. If there's interest in making it an official part of distutils, it would maybe be better to actually rewrite the involved parts of distutils instead of trying to subclass them (in fragile ways).

You'd most probably break lots of existing code out there which already does this. IMHO, the right path to choose would be to factor out some parts which then provide better and cleaner ways to hook into via subclassing. Some methods in distutils are rather convoluted (e.g. various .run() methods and adding something to the middle of these methods usually turns out to be a copy & insert procedure which is not ideal (and usually breaks every now and then if you upgrade distutils). -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Mar 14 2003)

...

...

Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

Python UK 2003, Oxford: 18 days left EuroPython 2003, Charleroi, Belgium: 102 days left