You are not logged in.
Hi,
The option doesn't seem to work. It's supposed to be the default option anyway.
[env]$ virtualenv2 --no-site-packages mypython
The --no-site-packages flag is deprecated; it is now the default behavior.
New python executable in mypython/bin/python2
Also creating executable in mypython/bin/python
Installing setuptools............done.
Installing pip...............done.
[env]$
activation, yolk, etc...
(mypython)[env]$ yolk -l
Python - 2.7.2 - active development (/usr/lib/python2.7/lib-dynload)
pip - 1.1 - active
setuptools - 0.6c11 - active
wsgiref - 0.1.2 - active development (/usr/lib/python2.7)
yolk - 0.4.3 - active
(mypython)[env]$ pip install python==2.7.2
Requirement already satisfied (use --upgrade to upgrade): python==2.7.2 in /usr/lib/python2.7/lib-dynload
Cleaning up...
(mypython)[env]$
virtualenv obviously refuses to install python into mypython, though it should not. Why?
Last edited by Llama (2012-03-27 11:20:31)
Offline
Read the documentation again. "--no-site-packages" doesn't work as you seem to expect. In no case you need to explicitly install Python into the virtualenv. A virtualenv always contains an isolated Python.
Offline
That's a relief.
You mean that a line like this
wsgiref - 0.1.2 - active development (/usr/lib/python2.7)
suggests that my environment contains an isolated wsgrief. Fine by me.
The total size of my mypython directory is 1.3 MiB. I have some trouble believing the whole Python is that lightweight.
Offline
I believe that you've somehow misunderstood, how virtualenv work. virtualenv doesn't give isolated copies of modules, it gives you a completely fresh Python environment. In fact,However, you can install new 3rd party modules into the virtualenv without affecting the global Python or other virtualenvs.
If you create a virtualenv "foobar", virtualenv links all modules from the standard library into "foobar". If "--site-packages" is enabled, it also links all 3rd packages that were installed into the global Python into "foobar". Thus the "wsgiref" available in "foobar" is the very same as the one in the global Python "foobar" was created from. However, if you install new 3rd party modules into "foobar", these modules are only available in "foobar", but neither in the global Python nor in any other virtualenv. This is the very purpose of virtualenv: Enabling the installation of 3rd party packages without affecting the global Python interpreter.
The only difference between "--site-packages" and "--no-site-packages" is that with the former option, 3rd party modules installed into the global Python are also available in the virtualenv, whereas with the latter option the new virtualenv only contains Python the standard library without any 3rd party modules.
Offline
So environment it is, and nothing more. Does it follow that if my hosting, for instance, doesn't serve any Python, there's no way to upload it with my software? Do I have to use exactly the version of Python my hosting provides?
Offline
@Liama: No, virtualenv doesn't magically upload your Python environment to your hosting service. I wonder how you got this idea, because this scenario is never even mentioned in the documentation.
Virtualenvs are not intended to be send around. They are only intended to be used locally for development and deployment. virtualenv is not a tool to deploy a software on a remote system. How to do this depends on the kind of hosting service, and on the software that is provided by the hoster. But generally, you cannot deploy Python software on a hosting service that does not provide a Python interpreter.
You generally don't need to use exactly the same Python version as provided by your hoster, but you need to use one that is compatible to it. Refer to the Python documentation for more information about compatibility between different Python versions.
Offline
Thanks!
Virtualenvs are not intended to be send around. They are only intended to be used locally for development and deployment. virtualenv is not a tool to deploy a software on a remote system.
What could it have to do with a deployment scenario then?
Offline
@Liama: Aside of development and testing, "virtualenv" is typically also used to create isolated environments for each web application that is running on a server, to control dependencies, avoid version conflicts and keep the server clean of 3rd party packages. But this happens on the server itself, and not on your development system.
Offline
Thanks!
Offline