When building on a different (clean) platform, I get "[...] (version
55bd03e2e13c)". However, rebuilding the original executable on the first
platform yields 1.1.2. It seems that this is a sticky value somehow. (I had
1.1.2 before I built 1.2).

I've tried "make clean" in addition to simply deleting and re-cloning the source
repository, but I still get 1.1.2. Is it possible that some information is
stored outside the repository somewhere and "make clean" doesn't clobber this?
(The previous version, 1.1.2, was also built from source.) I'm afraid that I'm
not at all familiar with the Mercurial source (and have only just started using
Mercurial), so I can only really speculate about the possible causes.

Observation of "which hg" and file modification times shows that the executable
is being re-generated during the build, so this isn't a PATH masking issue.

Incidentally, I'm using Ubuntu 8.04 and I'm using "make install-home" to build
Mercurial.

Thanks,
Jacob

Hi JacobBramley,
 If I am guessing correctly, you had installed your previous version, i.e 1.1.2
from source using make install and not make install-home?

One suggestion I can tell at the moment is to define an Environmenl variable
PYTHONPATH set to your home installation's lib directory. From what I am seeing
in my attempt to reproduce this error, even though your hg main binary is
running from right location, the modules it imports internally are not the ones
which you have installed now, meaning you are still using old version of
mercurial :)

Since you said you are on Ubuntu, try adding this line to your $HOME/.bashrc (or
configuration file of
which ever shell you are using)
export PYTHONPATH=$HOME/lib/python
(The of install path of mercurial's modules is $HOME/lib/python since you said
you have run make install-home)
This should work fine. Please inform us what happened.

Ah yes, that's the problem. I thought I'd done install-home before too, but the
binaries got into /usr/local somehow so I must have done a system-wide
installation at some point. Apologies for the wild goose chase :-)

I'm sure this has already been discussed already, but one or more of the
following may help to prevent others from falling into the same trap that I did:
 * Provide an "uninstall" rule in the make file.
 * Scan ~/lib/python by default, just as many other paths are scanned by default.
 * Is it worth scanning ../lib/python?

Thanks!
Jacob

Providing uninstall is definitely a good idea. I won't deny it, but how do we
know where we have installed from our previous install? We can scan some common
paths, but that doesn't guarantee all the locations where the libraries may be
installed. I am sorry for strong words here, but I am suffering from this
problem. It is actually not possible to look at all the *stupid* paths that our
distributions would put these libraries in. It turns out to be extremely
distribution specific, which may be hard to search for during uninstall, because
you are most likely to run make uninstall from a new package with which you did
not install. 

 * Scan ~/lib/python by default, just as many other paths are scanned by default.
 * Is it worth scanning ../lib/python?
These 2 cases work only if you are sure of running make install-home last time,
which was clearly not the case for you, since you had not done install-home but
just install. Also in the environment I tested, I first installed my distro's
binary from the repo and then did install-home for 1.2 tar.gz package.

So considering all the above difficulties, I personally feel, a good idea for
now is to just clearly point out in the documentation(i.e README file and online
resource) to make sure to remove all the previous install libraries from where
ever we installed or install in the same method we did last time as many other
Python based projects do for now. 

Just my personal opinion. Will leave it for other contributors and developers
who definitely know about this better than me.

Yeah, I see your point.

Hmm. Is it possible to store the installation information in the hg binary
itself? It's not a perfect solution, but it's a possible workaround. For
example, "hg --libraries" could list the associated libraries, and a
hypothetical "make uninstall" could run this command to determine what to do.

I would also argue that scanning ../lib/python would work if it is scanned
_before_ the system-wide directories such as /usr/[...]. It's unlikely that a
user would have old libraries in $HOME along with new binaries as these
libraries are Mercurial-specific. Of course, it may happen, and things would
break in that case.

It would certainly help if distributions would use a better standardized
directory structure!

Thanks,
Jacob

Your idea of storing the installed libraries path in a binary or somewhere
accessible to it seems to be nice work around. But I would really wish some
developer, i.e a committer or any contributor who can really pester or bug a
committer to make this change pitch in and comment on this idea too. If some one
of that caliber gives a green signal I will try to put in what you are trying to
propose, I will also propose this on the IRC channel for further discussion,
today evening.

I completely missed your second para I feel. I did not understand why we need to
scan $HOME/lib/python? When we make install-home from a new copy if there are
any such installations, the new files anyways supersede the old ones, AFAIK. I
don't see any point in it.

And finally, *cough* *cough* for distributions. Only distributions can help
distributions ;-)

Basically, if ~/lib/python is scanned before /usr/local/lib/python, it doesn't
matter if a system-wide installation has an older version installed as an
individual user can build their own version in their home directory; a user's
own binaries will then mask the system binaries for that user.

For example, I did "make install" or something similar to get libraries in
/usr/local. If Mercurial scanned my home directory before /usr/local, then when
I later did "make install-home", the libraries in ~/usr/libs would have been hit
before the global ones, whilst other users on the system could still use the old
version.

It basically saves me from having to set PYTHONPATH, but I don't know how
consistent distributions are with their home directory structures so it may not
be a sensible default setting. (I'm no Linux expert!)

Anyway, thanks very much for your time!

Oh you meant while running Mercurial? I was pretty confused as to why we need to
scan ~/lib/python while running make uninstall. But what you propose again
becomes too one-sided. What if a user had done make install-home before and now
running make install? This method breaks.

A better approach I feel is to supersede the path of install over the previous
install path in your sys.path after each install, but that again depends on how
to do it for individual users. (Only way I can think as of now is to again set
PYTHONPATH :P )

Right, but if the user did "make install" they'd still hit the hg binary in
their home directory, so it makes sense for them to use the libraries in the
home directory. Of course, if they _want_ to use the global one and ditch the
local one, they could use a hypothetical "make uninstall-home" as before. If the
search path is "../lib/python", every hg binary would get the proper libraries.
However, I don't know enough about Linux distributions to know if that's safe in
the general case.

PYTHONPATH works for the libraries, but not the main binary.

Can one of you re-title this issue accordingly ? (I'm not sure what you want,
but the title is definitely not up-to-date). And maybe degrade it to feature or
wish.

thanks

I've changed the title and degraded this to a feature -- the problem seems to be
that a custom install requires a custom setting of the PYTHONPATH variable.

I'm not sure this is a bug, instead it is expected behavior when you install
Python software to a path outside PYTHONPATH.

Changeset 10da5a1f25dd addresses this by always loading mercurial from where 
it was installed.

Confirmed that the libraries in my local install, my user install, and my 
systemwide install don't conflict with one antoher.

(There could conceivably still be some edge cases when a directory was 
deleted, where someone may still need to set their PYTHONPATH, but not 
anything we can do about it at that point!)

For reference to anyone who might stumble across this issue -- "hg 
debuginstall" lists the path to the modules that hg is currently using.

--- Bug imported by bugzilla@serpentine.com 2012-05-12 08:57 EDT  ---

This bug was previously known as _bug_ 1544 at http://mercurial.selenic.com/bts/issue1544