[Distutils] Install a script to <prefix>/sbin instead of <prefix>/bin

[Michael Jansen]

> It would be fairly simple to propose adding the GNU coding standard
> directory variables:
> http://www.gnu.org/prep/standards/html_node/Directory-Variables.html .
> They could become valid names under the wheel .data/ directory.

It probably would. But i am a fan of only adding whats now needed. So i think just adding support 
for <prefix>/sbin and <prefix>/libexec would be enough for the problem i have at hand NOW.

I need support for <prefix>/etc to and the special handling for /usr/etc -> /etc too for some other 
stuff but i would like to do it one thing after the other. Lets first find out if its desired and possible 
to add something to distuils. It still is the base of all other build systems? Right?

After that perhaps adding those to setuptools scripts entry point should be the next step.

THEN i start to think about what i need for other stuff :) .

> You would also want to figure out how to instruct the installer to
> generate scripts wrappers for these alternative destinations so e.g.
> the execute bit is set and the #! line points to the correct
> interpreter.

Thats what my patch does. For <prefix>/sbin for now but support of the libexec directory is easy to 
add. But quite a bit of copy and paste programming.

So another idea i am thinking about is doing it like this:

scripts = [
   "bin/myscript3",		# <= backwardscompatible
   (  'bin/',    [ 'bin/myscript1', 'bin/myscript2' ] ),
   (  'sbin/',   [ 'sbin/mysbinscript1', 'sbin/mysbinscript2' ] ),
   (  'lib/myproject/libexec', [ 'libexec/script' ] )
   ]

So if its a string do it like always and if its a list/tuple do it like data_files does.

In an ideal world one could even expand those gnu standard vars in there. Like that:

scripts = [
   "bin/myscript3",		# <= backwardscompatibility
   (  '$bindir/',    [ 'bin/myscript1', 'bin/myscript2' ] ),
   (  '$sbindir/',   [ 'sbin/mysbinscript1', 'sbin/mysbinscript2' ] ),
   (  '$libexecdir', [ 'libexec/script' ] )
   ]

> It would be a good idea to consider the needs of Windows and
> virtualenv users who may need to be able to opt out of the "install
> things anywhere on my system" and "full FHS compliance" features.

At least the need for Windows is taken care of by INSTALL_SCHEME in distutils.command.install . 
The sbin directory is added like that:

if sys.version < "2.2":
    dist_install.WINDOWS_SCHEME['sbin_scripts'] = '$base/Scripts'
else:
    dist_install.WINDOWS_SCHEME['sbin_scripts'] = '$base/Scripts'

dist_install.INSTALL_SCHEMES['unix_prefix']['sbin_scripts'] = '$base/sbin'
dist_install.INSTALL_SCHEMES['unix_home']['sbin_scripts'] = '$base/sbin'
dist_install.INSTALL_SCHEMES['unix_user']['sbin_scripts'] = '$userbase/sbin'
dist_install.INSTALL_SCHEMES['nt_user']['sbin_scripts'] = '$userbase/Scripts'
dist_install.INSTALL_SCHEMES['os2']['sbin_scripts'] = '$base/Scripts'
dist_install.INSTALL_SCHEMES['os2_home']['sbin_scripts'] = '$userbase/sbin'

As you can see for windows the sbin scripts get installed into Scripts too. Same for os2 unless the 
--home option is active.

And virtualenv does not need any kind of special handling. It has to install the same just into a 
different prefix. Same should go for pyvenv ? .

All those new directories just have to be added there with correct values for all schemes.

Mike

-- 
Michael Jansen
http://michael-jansen.biz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20131203/0dd53d80/attachment.html>