> 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
_______________________________________________
Distutils-SIG maillist - [email protected]
https://mail.python.org/mailman/listinfo/distutils-sig
