Running Mercurial with a custom Python version: version mismatch

[Thomas De Schampheleire]

Hi Matt,

On Sat, Aug 30, 2014 at 10:24 AM, Matt Mackall <mpm at selenic.com> wrote:
> On Fri, 2014-08-29 at 20:13 +0200, Thomas De Schampheleire wrote:
>> Hi Matt,
>>
>> On Fri, Aug 29, 2014 at 6:23 PM, Matt Mackall <mpm at selenic.com> wrote:
>> [..]
>> >
>> > On the other hand, it's trivial to install multiple versions of
>> > Mercurial linked against multiple versions of Python:
>> >
>> > $ hg clone hg hg3.1-python2.5
>> > $ cd hg3.1-python2.5
>> > $ hg co 3.1
>> > $ make PYTHON=python2.5 local
>> > $ ln -s $PWD/hg ~/bin/hg3.1-python2.5
>> >
>> > (I actually have over 100 releases of Mercurial in my path..)
>>
>> Wouldn't it make sense that Mercurial remembers which Python path was
>> used in the installation and reuses the same path throughout its
>> future execution?
>
> But it does!
>
> Specifically, when you do "python setup.py", setup.py uses the path of
> the running python and replaces the "shebang" line at the start of the
> installed hg to use it. Usually, this is /usr/bin/python, so if you
> change _that_, you break things. We also internally store the path of
> the Mercurial libraries that are installed (see @libdir@).
>
> If this isn't working, then something is wrong with your setup process.

I now realized my mistake: I had been testing the new Mercurial
installation using 'make local' and apparently this does not perform
the steps you described.
As soon as I switch to a regular install with a custom PREFIX, the
python path was indeed hardcoded as expected.

Is there a specific reason for not performing these steps in the 'make
local' case?

>
>> The method you suggest requires the users to be fully aware of the
>> python version in place and create a local Mercurial installation to
>> match it.
>>
>> For a system administrator that wants to upgrade Mercurial from a
>> release where the check is not yet in place (for example Mercurial
>> 2.6) to Mercurial 3.1, this is challenging as Mercurial will suddenly
>> fail to work for users that have a custom Python version.
>
> Again, this is good. This means you will not have silent C-level API
> breakage that corrupts your repo and causes you to send us
> impossible-to-diagnose bug reports. We're not just making it break to be
> mean.

I already guessed that :-)

Thanks for your help,
Thomas