[Python-apps-team] mercurial spec broken

[Vincent Danjean]

timeless wrote:
> Dan Villiom Podlaski Christiansen wrote:
>> 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.
> 
> i don't like doing this at all. if a user wants to use that set of
> templates, let the user add a symlink to them into their local
> mercurial install. I for one *never* want the vendor packaged crud and
> hate when it interferes with my life. (this especially applies to
> things where the vendor enabled obsolete or buggy or broken or missing
> extensions.)

It is hardcoded but at the end of directories that are tried :
--- a/mercurial/templater.py
+++ b/mercurial/templater.py
@@ -9,7 +9,7 @@
 import re, sys, os
 import util, config, templatefilters

-path = ['templates', '../templates']
+path = ['templates', '../templates', '/usr/share/mercurial/templates']
 stringify = templatefilters.stringify

 def parsestring(s, quoted=True):
So, if you put your templates where 'standard' mercurial put them, they will
be used.

About paths, the Debian package also changes the directory for help files:
they are put in /usr/share/mercurial/help
The goal of these two changes is that Debian packages fully respect the FSH
(ie arch independant files in /usr/share/package). Other distro might be
interested but I fully understand it is not necessarily a good thing for
local installs.

While I am at it, there are three patched in the Debian package that can be
interesting upstream:
- one that rewrite the doc for zeroconf (proposed by a user)
- one that does not install i18n files (they are only useful for developers
  and translators, not for users)
- one that remove the shangline from modules that are used as modules and
  not as plain programs (ie not installed in /usr/bin nor invoked directly)

  Regards,
    Vincent

>> 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.
> 
> this i really really want. i'm constantly screwed by distros. on this point.
> 
> these days, i basically do:
> sudo apt-get install mercurial
> hg clone path/to/hg-crew
> cd hg-crew
> make install-home
> sudo apt-get remove mercurial mercurial-common
> 
> if i forget to remove mercurial/mercurial-common, i end up using a
> really ancient version of mercurial.
> 


-- 
Vincent Danjean                 Adresse: Laboratoire d'Informatique de Grenoble
Téléphone:  +33 4 76 61 20 11            ENSIMAG - antenne de Montbonnot
Fax:        +33 4 76 61 20 99            ZIRST 51, avenue Jean Kuntzmann
Email: Vincent.Danjean at imag.fr           38330 Montbonnot Saint Martin