[Python-apps-team] Bug#620087: mercurial: /usr/bin/hg prepends /usr/lib/python2.5/site-packages/ to sys.path

Stefano Rivera stefanor at debian.org
Wed Mar 30 08:06:06 UTC 2011


Hi Thomas (2011.03.30_09:17:22_+0200)
> Mercurial's Makefile always uses --force for this and a few other
> reaons, but ...

My reasoning is that it's preferable to not have /usr/bin/hg differ
between the two builds. And when Debian enables python 2.7, it won't
start out as the default, which would mean we'd want the 2.6 version...

> > -            'install_scripts': hginstallscripts}
> > +# Disabled on Debian. We install into the public namespace and don't need
> > +# to hack sys.path.
> > +#            'install_scripts': hginstallscripts}
> 
> ... with the comment this looks good, too.

The downside here is that hginstallscripts might do more magic in the
future.

> Maybe it would be good to change hginstallscripts upstream so it
> doesn't do @LIBDIR@ magic if this would be in the public namespace?
> How can this be detected in a reliable way?

Seeing if --install-* has been set at all, would be a start.

BTW, the Ubuntu submitter and I popped into #mercurial, but didn't get
any useful discussion. Explaining that we support multiple python
versions seemed to cause confusion :)


Replying to Javi:
> The patch should just replace the 'install_scripts' line with a line
> with "}". Add the comments at the beginning of the patch file, and
> please start the name of the patch with "deb_specific__".

Righto.

> You can go ahead, yes. As Thomas pointed out, this should be a temporal
> hack while it is fixed upstream. I won't have time in the following week
> (I hope this doesn't break things horribly), but while this may work
> now, it may break in the future if mercurial devs add more stuff to
> hginstallscripts, so we should try to fix it upstream.

Yeah, that also worries me a little. Alternatives are to exit out of
hginstallscripts before rewriting, or to patch /usr/bin/hg itself (but
I'd rather it was the same in both python version's installs).


Replying to myself:
> Resulting in a crash:
> > AttributeError: 'module' object has no attribute 'BufferedIOBase'
> http://paste.ubuntu.com/587028/

I only realised later (thanks Jakub Wilk) that this issue shouldn't
cause this particular crash, as there shouldn't be anything mercurial
related in /usr/lib/python2.5/site-packages/. I couldn't reproduce it
(or I'd have used a higher severity). This means I feel less urgency
here, but it's still clearly wrong to put a python 2.5 package path in
2.6's sys.path, and asking for trouble.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559  UCT: x3127





More information about the Python-apps-team mailing list