[Distutils] pythonv, take two

Vinay Sajip vinay_sajip at yahoo.co.uk
Thu Mar 31 13:10:11 CEST 2011


Carl Meyer <carl <at> oddbird.net> writes:

> Hmm, it doesn't seem to be working for me. sys.prefix and
> sys.exec_prefix are still /usr/local using the python binary in my
> "pmv", and sys.virtual_prefix is not set at all, despite env.cfg being
> present and looking as it should.
> 
> Oddly when I run the compiled python binary directly from the checkout,
> it does set sys.virtual_prefix to point one level above the checkout,
> despite there being no env.cfg in the vicinity at all.
> 
> You can see both of these things (in reverse order) here:
> http://paste.pocoo.org/show/362798/

After testing on a machine with no Python 3.3 installed, I get a similar failure
to yours (invalid Python installation due to missing Makefile). However, rhe
getpath.c code seems to be working as expected: see
http://paste.pocoo.org/show/363159/ for example. The path has been set to
reflect the source build where the python was copied from. Of course at this
point virtualize() hasn't been called, so virtual_prefix etc. haven't been set,
and prefixes are pointing to /usr/local.

I think the problem is occurring because there's incomplete support for running
from a source build. I'm not sure what to do about this; I think proper support
will need changes in multiple other places, which I haven't bottomed out yet but
which includes distutils.sysconfig (see issue #6087). Since running from a
source build does not set sys.prefix and sys.exec_prefix, either this needs to
change, or there needs to be some additional concept like "sys.python_home"
which is available to scripts, or perhaps something else. Of course fixing the
source build issue is of use only for core developers, so I'm not sure what
appetite there'd be for regularising things for this case.

Regards,

Vinay Sajip



More information about the Distutils-SIG mailing list