Installing scripts to multiple directories
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".
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.
Have anyone done this particular extension already? If not, are there any guidelines on how such an extension ought to be done?
[1] Bug id 452144, viewable at http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452144&a...
Harald Meland Harald.Meland@usit.uio.no 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.
[Michael Hudson]
Harald Meland Harald.Meland@usit.uio.no 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.
OK.
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.
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).
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).
Any thoughts on what implementation past I should choose?
The distutils are a thing of wonder, but the code isn't the easiest to understand in the world.
True. :-)
Harald Meland wrote:
[Michael Hudson]
Harald Meland Harald.Meland@usit.uio.no 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).
participants (3)
-
Harald Meland -
M.-A. Lemburg -
Michael Hudson