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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
