[Python-apps-team] mercurial spec broken

[Martin Geisler]

Dan Villiom Podlaski Christiansen <danchr at gmail.com> writes:

>> 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've not installed that many big Python applications, but my experience
is that setup.py will install Python files, C extensions, and binaries.
I think documentation and man pages are often left behind in the
installation folder.

>> 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 note 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.

The Debian patch[1] simply appends '/usr/share/mercurial/templates' to
the search path for the template engine. I think we could take such a
change upstream, especially if it turns out that other distributions
would benefit from it too.

[1]: http://ftp.debian.org/debian/pool/main/m/mercurial/mercurial_1.4.1-1.diff.gz

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.