On 01.06.2015 19:58, Carl Meyer wrote:
Hi,
On 06/01/2015 03:05 AM, M.-A. Lemburg wrote:
If you want to have a system that doesn't require activation, you may want to take a look at what we've done with PyRun:
Virtualenv doesn't require activation either.
Activation is a convenience for running repeated commands in the virtualenv context, but all it does is change your shell PATH; you can explicitly specify the virtualenv's python binary and never use activation, if you wish.
Ok, I was always under the impression that the activation script also does other magic to have the virtualenv Python find the right settings. That's good to know, thanks.
http://www.egenix.com/products/python/PyRun/
It basically takes the "virtual" out of virtualenvs. Instead of creating a local symlinked copy of your host Python installation, you create a completely separate Python installation (which isn't much heavier than a virtualenv due to the way this is done).
Virtualenv doesn't create "a local symlinked copy of your host Python installation." It copies the binary, symlinks a few key stdlib modules that are necessary to bootstrap site.py, and then its custom site.py finds the host Python's stdlib directory and adds it to `sys.path`.
Well, this is what I call a symlinked copy :-) It still points to the system installed Python for the stdlib, shared mods and include files.
Once installed, everything works relative to the PyRun binary, so you don't need to activate anything when running code inside your installation: you just need to run the right PyRun binary and this automatically gives you access to everything else you installed in your environment.
This is exactly how virtualenv (and pyvenv in Python 3.3+) works. Everything is relative to the Python binary in the virtualenv (this behavior is built into the Python executable, actually). You can just directly run the virtualenv's Python binary (or any script with that Python binary in its shebang, which includes all pip or easy-installed scripts in the virtualenv's bin/ dir), without ever activating anything.
It seems the main difference between virtualenv and PyRun is in how much of the standard library is bundled with each environment,
The main difference is that PyRun is a stand-alone Python runtime which doesn't depend on the system Python installation at all. We created it to no longer have to worry about supporting dozens of different Python installation variants on Unix platforms and it turned out to be small enough to just always use instead of virtualenv.
and that I guess PyRun doesn't come with any convenience activation shell script? But the method by which "activation" actually occurs is identical (at least as far as you're described it here.)
After what you've explained, the sys.path setup is indeed very similar (well, PyRun doesn't really need much of it since almost the whole Python stdlib is baked into the binary). What virtualenv doesn't appear to do is update sysconfig to point to the virtualenv environment instead of the host system.
Carl
In our latest release, we've added requirements.txt support to the installation helper install-pyrun, so that you can run
install-pyrun -r requirements.txt .
to bootstrap a complete project environment with one command.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 01 2015)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ mxODBC Plone/Zope Database Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/