> From: Paul Moore <p.f.mo...@gmail.com> > But nevertheless, for my current usage, distil install foo is 99% of the time > a > user error, as I maintain a completely clean system Python, and do all my > package installs in virtualenvs. Maybe the per-user site packages is something > I should be using, and if I do, then I can afford to be less obsessive about > keeping > my system Python clean. But until distil became available, I haven't had the > tools to > work with the user site packages directory, so it's new ground for me.
If you do all your package installs into venvs, then isn't "distil -e venvdir install foo" enough? You don't need to activate the venv, just tell distil which venv to install into via the -e. > The one thing that *is* different between Unix and Windows is that on Unix, > the > hashbang line of #!/usr/bin/env python will use the currently active Python > (system or > virtualenv as appropriate) but under Windows it will always use the system > Python (2 > or 3 depending on py.ini). Maybe the launcher should treat /sur/bin/env > python differently, > and try looking on PATH before using the default in that case, but that's not > how it works, > sadly (indeed, there's no way of getting that behaviour with the current > launcher). I can > imagine having a virtualenv active and running distil install foo and being > surprised that the > install doesn't go to the active virtualenv. I have implemented path searching in the launcher, but it's currently disabled. I can re-enable it (such that the path is only searched if the PYLAUNCH_SEARCHPATH environment variable is set) and create a new release of the standalone launcher - are you willing to be a guinea pig for this functionality? Regards, Vinay Sajip _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig