[Python-apps-team] mercurial spec broken

[Dan Villiom Podlaski Christiansen]

On 7 Dec 2009, at 10:12, Martin Geisler wrote:

> Gilles Moris <gilles.moris at free.fr> writes:
> 
>> Hi Guys,
>> 
>> The contrib/mercurial.spec file has been broken by the rename of
>> bash/zsh completion scripts. This can be fixed but ...
>> 
>> As they are now handled by setup.py, they are by default already in
>> the RPM with a separate path:
> 
>> /usr/share/bash_completion.d/hg
>> /usr/share/zsh/site-functions/_hg
>> 
>> when they were previously in:
>> /etc/bash_completion.d/mercurial.sh
>> /usr/share/zsh/site-functions/_mercurial
>> 
>> So how do you see it:
>> - rename the files again and change the setup.py again to match the
>>  spec file
>> - have them on both locations
>> - get rid of the previous location but break compatibility
>> - other / hybrid solution
> 
> Well, I talked about it with Mads yesterday, and the more I look at it,
> the more it seems to me that we should not let setup.py install such
> things. It just seems like there are too many special cases for us to
> know them all in a single setup.py.

I agree that we shouldn't install the completion files. Originally, I chose a bunch of files somewhat arbitrarily to test the functionality, without knowing much about whether installing each one was a good idea or not.

> I'm almost at the point where I would say that we should
> 
> * let setup.py build the C extensions
> * install them and the Python files
> 
> That's it... a very thin setup.py file which is mostly used for what it
> does best: build C extensions. So users will have to use the Makefile to
> build man pages and to compile the translations.

I think that will break user expectations; most Python software can be installed with distutils alone, and I believe Mercurial ought to provide a fairly complete experience when installed as such.

> I hope distributions can then call setup.py with the right options to
> make it install the Python modules in the right location.
> 
> Mads and I noticed yesterday that the Debian package is patching
> Mercurial so that the templates are in
> 
>  /usr/share/mercurial/templates
> 
> instead of
> 
>  PREFIX/lib/site-packages/mercurial/templates
> 
> Should we try to support this upstream? I've CC'ed the Debian package
> maintainers -- please talk to us about such changes. What can we do to
> make your life easier?

While this would be a nice goal to have, you should not that it won't be quite as easy to do for us as the Debian maintainers. I suspect they just hard-coded ‘/usr/share/…’ into the sources, whereas we would have to make it configurable. 

If we decided to fix this, there is a related issue we might want to look into: modifying ‘sys.path’ to bind a ‘hg’ script to its libraries. The advantages of this would be two-fold:

1) Users wouldn't need to set $PYTHONPATH should they install Mercurial in a non-standard path.
2) Users who have more than one installation available — say, one of them part of some distribution — could invoke either one more easily.

--

Dan Villiom Podlaski Christiansen
danchr at gmail.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1943 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/python-apps-team/attachments/20091207/049bcfd1/attachment.bin>