[Distutils] pythonv, take two

[Vinay Sajip]

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

> So... it seems to me that we're likely to break _some_ third-party code
> using sys.prefix regardless of what we do here. My instinct says adding
> sys.virtual_prefix and leaving sys.prefix alone is the better approach,
> but I'm not very firmly entrenched in that position.

That's problematic, of course (third-party breakage, I mean). It may be that
despite using virtual_prefix being a cleaner approach, it may be necessary
to alter sys.prefix to ensure compatibility, a la virtualenv.

> 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/
> 
> I'll dig in a bit more and see if I can figure out what's happening.

It may be that the thing isn't working properly, but it's masked on my
system because I have an installed 3.3 in /usr/local (from when I was doing
my pip/virtualenv tests). This means that there is a Makefile in a location
which would not be there if I'd never installed 3.3 using sudo make install.

However, the getpath.c stuff should work - to test this, insert an
"import pdb; pdb.set_trace()" in site.main, and check sys.path. This should
contain entries from the virtualenv. The problems are more likely to be in
the Python code: the C code always sets sys.prefix and sys.exec_prefix to
/usr/local (or whatever configure was invoked with) and the sys.prefix /
sys.exec_prefix stuff is done in site.virtualize, as before.

I'll try to test this on a machine which never had 3.3 installed - it seems
you can't uninstall Python using sudo make uninstall :-(

> Is there a reason you didn't base your changesets on mine (in the
> cpythonv repo), and instead apparently copied over a bunch of the
> changes manually as a diff? I can transplant or copy your work back, or
> try to do a full merge, but in the long run if we'll both be working on
> this it seems best if we are easily able to merge our work back and forth.

Sorry - I got in a muddle because I've got too many clones around and ran
into free disk space issues, and goofed somewhere. Don't bother to do a full
merge for now, as I'm not sure if my code's working yet. Since I don't expect
to change more than 4 files (getpath.c, site.py, distutils/sysconfig.py and
sysconfig.py) I don't think we'll have too much trouble merging in due
course, and if/when we can agree that my experiment in pythonv is worth
taking further, I'll do the work of merging into cpythonv. For now, though,
my changes might be treading on your toes, making merging needlessly
annoying.

I'll try to test on a Python-clean machine in a day or two, will report back
then.

Regards,

Vinay