Understanding virtual environment paths

[Luisa Beck]

I have a question about virtual environments:

Say I've activated a virtual environment. I'm working with SQlite3 (already installed on my Mac 10.6.8) and I save a .db file outside of my project directory. 

If I save the path outside the project directory, will I still have access to it when I'm in the virtual environment?

(I'm imagining the virtual environment like a sandbox around my project. I can play with the things I put into the sandbox.) So when I place a file outside of that, can I still access it when my virtual environment is active?

[André Dieb]

The virtual environment is like a sandbox that has its own python executable and its own python libraries. Your .db file is perfectly accessible from inside the env.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/MdQuwsP-lB8J.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

--
@andredieb

[Javier Guerra Giraldez]

On Wed, Nov 21, 2012 at 7:30 PM, Luisa Beck <emmi...@gmail.com> wrote:
> (I'm imagining the virtual environment like a sandbox around my project. I
> can play with the things I put into the sandbox.) So when I place a file
> outside of that, can I still access it when my virtual environment is
> active?

the 'sandboxing' of the virtual environment is not like chroot or a
virtual machine:

- it's only about what python code you use, not about what that code
can do. the whole machine's resources are still accessible: the whole
filesystem(s), RAM, network, etc. it's just a different Python
installation that doesn't conflict with what you already have, or with
other virtualenvs.

- it's not about security, but about reducing mistakes. there's
nothing to block you from accessing anything outside the environment.
just the defaults are set up so you have to intentionally do it, not
by accident.

--
Javier

[Luisa Beck]

Hi Javier, 

That's super helpful. Thank you! Just to make sure I'm understanding correctly:

You write "there's nothing to block you from accessing anything outside the environment. 

just the defaults are set up so you have to intentionally do it, not by accident."

So in other words, the virtual environments let me temporarily change my default settings. And when I step out of the virtual environment, the system's default settings are used instead. But say I create a virtual environment and install a script that depends on another script that I haven't included in the virtual environment. That leads me to an error because the script can't be found in that virtual environment. Why doesn't the interpreter then look outside of my virtual environment? Or do I need to specify this in the interpreter's path somewhere?

Thanks!

[Javier Guerra Giraldez]

On Thu, Nov 22, 2012 at 10:19 AM, Luisa Beck <emmi...@gmail.com> wrote:
> But say I create a virtual environment and install a script that depends on
> another script that I haven't included in the virtual environment. That
> leads me to an error because the script can't be found in that virtual
> environment. Why doesn't the interpreter then look outside of my virtual
> environment?

what does "depends on another script" means? usually it's that
somewhere you have a line like "import otherscript".

try this

python -c 'import sys;print sys.path'

both inside and outside a virtualenv. that's the main thing
virtualenv manages: the list of directories where the intepreter looks
for python code.

i hope that will explain why you get that error. the idea of
virtualenv is that by limiting where the interpreter looks for code
makes it easy to know what are your dependencies. If it was allowed
to look behind your back, you'll soon start depending on code that you
didn't install without realizing it.


the other big part of what virtualenv does is to interact with pip, so
when you say "pip install Django" (or any other python-only package),
it knows to install it within the virtualenv path. (modules that
compile a C extension also work, but not so easily).

finally, this means that you can simply do "pip freeze >
requirements.txt" to get a list of exactly what packages (and the
version of each one) are in your virtualenv, and therefore accessible
to your project. keep the requirements.txt file on the same version
control as the rest of the project, and deployment becomes little more
than:

- create virtualenv on server, activate it
- check out your project
- pip install -r requirements.txt
- ./manage.py syncdb



--
Javier