[PATCH 2 of 3 RFC] setup: install some useful data files

[Dan Villiom Podlaski Christiansen]

On 20 Nov 2009, at 14:01, Benoit Boissinot wrote:

>> +# on UNIX-like systems, the distutils default is install data directly in
>> +# $PREFIX, $HOME or whatever the base is. In such cases, change the default
>> +# to the standard `share' directory.
>> +for platform, scheme in INSTALL_SCHEMES.iteritems():
>> +  if platform.split('_', 1)[0] == 'unix':
> 
> platform.startswith('unix_') as a bit simpler

You're right, although they aren't *entirely* equivalent, as the latter doesn't catch a platform of 'unix'. Still, none of the relevant Python versions provide that, so I'll just use the replacement.[1] 

>> +    if scheme['data'][0] == '$' and '/' not in scheme['data']:
>> +      scheme['data'] += '/share'
>> +
>> extra = {}
>> scripts = ['hg']
>> if os.name == 'nt':
>> @@ -271,7 +280,14 @@ if sys.platform == 'linux2' and os.uname
>>                                      ['hgext/inotify/linux/_inotify.c']))
>>         packages.extend(['hgext.inotify', 'hgext.inotify.linux'])
>> 
>> -datafiles = []
>> +datafiles = [
>> +    ('bash_completion.d', ['contrib/completion/bash/hg']),
>> +    ('zsh/site-functions', ['contrib/completion/zsh/_hg']),
>> +    ('mercurial/www', ['hgweb.cgi', 'hgwebdir.cgi',
>> +                       'contrib/hgwebdir.fcgi',
>> +                       'contrib/hgwebdir.wsgi']),
>> +    ('mercurial/examples', ['contrib/sample.hgrc', 'contrib/mergetools.hgrc']),
>> +]
> 
> Having the templates in lib wasn't very clean. If we do that could we
> move them in share too? and the i18n in /usr/share/locale etc.
> 
> (I'm not sure what the proper directory is for everything, but I'm
> pretty sure we put more stuff than needed in lib).

While I agree that this should be the goal, it's not simple to achieve. Unfortunately, these paths aren't yet known in the build stage, as only the installation stage has knowledge of them.[2] I believe we'd have to roll our own solution, somehow. I don't see another way of doing this than hard-coding the data path into either the ‘hg’ script, another Python module or a package data file.

In my opinion, there are other things that have a more concrete and achievable value: I'd like to change the way __version__.py is generated, so that rather than forking another Python instance, Mercurial is imported into the building process. Preferably, we'd do the import from the build directory, and also put the generated file there. This should remove the — likely fragile — hacks the current approach employs on Windows.

--

Dan Villiom Podlaski Christiansen
danchr at gmail.com


[1] I ran this scriptlet:
$ for i in python{2.4,2.5,2.6,3.1}; $i -c 'from distutils.command.install import INSTALL_SCHEMES; print(": " + ", ".join([k for k in INSTALL_SCHEMES if k[0] == "u"]))'
: unix_prefix, unix_home
: unix_prefix, unix_home
: unix_prefix, unix_user, unix_home
: unix_prefix, unix_user, unix_home

[2] Two discussions on the Distutils-SIG list about this:
“obtaining easy_install prefix in setup.py”
<http://mail.python.org/pipermail/distutils-sig/2009-November/014627.html>
“Install time prefixes and data files”
<http://mail.python.org/pipermail/distutils-sig/2009-November/014424.html>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1943 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20091120/a2882775/attachment.bin>