hg --version reports version unknown

[J. Lewis Muir]

On Ubuntu Linux 10.04 LTS, after installing Mercurial from the 1.7.2
source release, "hg --version" reports "version unknown":

===
$ hg --version
Mercurial Distributed SCM (version unknown)
(see http://mercurial.selenic.com for more information)

Copyright (C) 2005-2010 Matt Mackall and others
This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
===

Why is this, or how do I fix it?

I ran the following commands to build from source and run hg:

$ cd /usr/local/src
$ tar xzvf ~/Downloads/mercurial-1.7.2.tar.gz
$ cd mercurial-1.7.2
$ make all
$ sudo make PREFIX=/usr/local install
$ make clean
$ cd
$ hg --version

I noticed "unknown" in the egg-info file name too:

$ ls /usr/local/lib/python2.6/dist-packages
hgext mercurial mercurial-unknown-py2.6.egg-info

I also tried the "local" target which had the same result:

$ make local
$ ./hg --version

The version of Python is 2.6.5. The hardware architecture is 32-bit
x86. I do not have the Ubuntu Mercurial package installed.

Thanks,

Lewis
_______________________________________________
Mercurial mailing list
Merc...@selenic.com
http://selenic.com/mailman/listinfo/mercurial

[Matt Mackall]

On Tue, 2010-12-07 at 12:05 -0600, J. Lewis Muir wrote:
> On Ubuntu Linux 10.04 LTS, after installing Mercurial from the 1.7.2
> source release, "hg --version" reports "version unknown":
>
> ===
> $ hg --version
> Mercurial Distributed SCM (version unknown)
> (see http://mercurial.selenic.com for more information)
>
> Copyright (C) 2005-2010 Matt Mackall and others
> This is free software; see the source for copying conditions. There is
> NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> ===
>
> Why is this, or how do I fix it?
>
> I ran the following commands to build from source and run hg:
>
> $ cd /usr/local/src
> $ tar xzvf ~/Downloads/mercurial-1.7.2.tar.gz
> $ cd mercurial-1.7.2
> $ make all
> $ sudo make PREFIX=/usr/local install
> $ make clean
> $ cd
> $ hg --version
>
> I noticed "unknown" in the egg-info file name too:

I was puzzled right up until this line. If you've got an egg installed,
it'll likely helpfully making a mess of Mercurial's module search path.

First ensure you have only one copy of hg in your path

$ which -a hg
/home/mpm/bin/hg

Then try the debuginstall command, you should get something like this:

$ hg debuginstall
Checking encoding (UTF-8)...
Checking installed modules (/home/mpm/hg/mercurial)...
Checking templates...
Checking patch...
Checking commit editor...
Checking username...
No problems detected

That'll tell you where Mercurial thinks its modules are. In 1.7.x,
Mercurial hardcodes its library path in the installed executable.

As a general rule, you shouldn't mix and match package management
systems, as none of them makes any effort not to stomp on the toes of
the others. If you install package X from an egg, and then later install
it from a .deb or from a tarball, you should expect to lose.

--
Mathematics is the supreme nostalgia of our time.

[J. Lewis Muir]

On 12/7/10 1:55 PM, Matt Mackall wrote:
> On Tue, 2010-12-07 at 12:05 -0600, J. Lewis Muir wrote:
>> I noticed "unknown" in the egg-info file name too:
>
> I was puzzled right up until this line. If you've got an egg installed,
> it'll likely helpfully making a mess of Mercurial's module search path.
>
> First ensure you have only one copy of hg in your path
>
> $ which -a hg
> /home/mpm/bin/hg

OK.

$ which -a hg
/usr/local/bin/hg

> Then try the debuginstall command, you should get something like this:
>
> $ hg debuginstall
> Checking encoding (UTF-8)...
> Checking installed modules (/home/mpm/hg/mercurial)...
> Checking templates...
> Checking patch...
> Checking commit editor...
> Checking username...
> No problems detected
>
> That'll tell you where Mercurial thinks its modules are. In 1.7.x,
> Mercurial hardcodes its library path in the installed executable.

$ hg debuginstall
Checking encoding (UTF-8)...
Checking installed modules

(/usr/local/lib/python2.6/dist-packages/mercurial)...

Checking templates...
Checking patch...
Checking commit editor...
Checking username...
No problems detected

> As a general rule, you shouldn't mix and match package management

> systems, as none of them makes any effort not to stomp on the toes of
> the others. If you install package X from an egg, and then later install
> it from a .deb or from a tarball, you should expect to lose.

Agreed. I've installed all software via the Ubuntu package management
system except for Mercurial. The Ubuntu mercurial package is at version
1.4.3. Since I want the latest version, I'm installing from the 1.7.2
source release. I hope this is fine.

The mercurial-unknown-py2.6.egg-info file was installed by the Mercurial
1.7.2 source release "install" target when I did:

$ sudo make PREFIX=/usr/local install

Thanks,

Lewis

[J. Lewis Muir]

Hmm, it works now. I decided to blow away the 1.7.2 source directory
and extract it from the tar.gz file again. After the same steps, it
reports the version correctly and creates the .egg-info file with the
correct version in the name.

The only difference is that with the old source directory, I had a few
failed target makes due to missing packages. The first failure was that
I needed to install the python2.6-dev package. After installing that
package, I did a "make clean" and then encountered the second failure
which was that I needed the python-docutils package. After installing
that package, I did a "make clean" and then the regular steps.

I thought perhaps the "clean" target wasn't cleaning everything and thus
leaving some state behind which caused the bad build and install, but a
diff of the old source directory after a "make clean" and the new source
directory after a "make clean" shows no differences. Puzzling.

I'll try to reproduce this. Any ideas?

[Matt Mackall]

On Tue, 2010-12-07 at 14:44 -0600, J. Lewis Muir wrote:
> I thought perhaps the "clean" target wasn't cleaning everything and thus
> leaving some state behind which caused the bad build and install, but a
> diff of the old source directory after a "make clean" and the new source
> directory after a "make clean" shows no differences. Puzzling.

'make clean' deleted the file containing the version number that's
shipped in the tarball but is normally built by examining the
repository.

--
Mathematics is the supreme nostalgia of our time.

[J. Lewis Muir]

On 12/7/10 2:46 PM, Matt Mackall wrote:
> On Tue, 2010-12-07 at 14:44 -0600, J. Lewis Muir wrote:
>> I thought perhaps the "clean" target wasn't cleaning everything and thus
>> leaving some state behind which caused the bad build and install, but a
>> diff of the old source directory after a "make clean" and the new source
>> directory after a "make clean" shows no differences. Puzzling.
>
> 'make clean' deleted the file containing the version number that's
> shipped in the tarball but is normally built by examining the
> repository.

Bingo. Thanks for your help with this.

Attached is a patch against the 1.7.2 .tar.gz source release to fix
this. It makes "make clean" only delete mercurial/__version__.py if the
directory .hg exists. Obviously, there are many ways to do this, but
the idea is that if we're in the directory extracted from the .tar.gz
source release, we likely won't have a .hg directory and can conclude
that we should not delete mercurial/__version__.py in this case.

Thanks,

Lewis