Running Mercurial with a custom Python version: version mismatch
Matt Mackall
mpm at selenic.com
Sat Aug 30 08:24:01 UTC 2014
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.
> 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.
--
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial
mailing list