I have virtual env called env1
I'm activating it via: source env1/bin/activate.
It does seem to be activated however if I simply run:
python
I can't import any packages I have in my virtual env. This seems to be the case with every virtual environment I have on this machine.
What's wrong with my system? or am I doing something wrong myself?
Its hard to tell just by your description but:
Activated environment will (in most linux distros) prefix your shell prompt with the name of environment. Like:
username#computer ~ $ source env1/bin/activate
(env1)username#computer ~ $ python
That should run you python from env/bin/python
Be sure that you have installed all packages you want included. Virtual environment can also be set to include or omit system packages. It is easily set during creation of virtualenv by including --system-site-packages argument.
See: http://virtualenv.readthedocs.org/en/latest/virtualenv.html#the-system-site-packages-option
Related
I use vevn with python 3.6.8, pip 18.1.
I set powershell executionPolicy RemoteSigned,
create virtual environment with venv, refed to venv official site : (https://docs.python.org/3.6/library/venv.html)
and also activated according to powershell, used .<venv>\Scripts\activate.ps1
But when I execute 'pip list' command, it shows all packages installed in global, not in venv.
And when execute python - import sys - sys.prefix, to check python directory,
I can find, powershell venv uses environmental variables python.
Of course, run it on cmd in same way, it works correctly.
pip list shows
The pip list shows only packages installed in venv, and sys.prefix is python in venv directory.
Does anyone know why it works like this?
Powershell works correctly like cmd
Maybe you activated the "--system-site-packages" switch by accident when installing the virtual env. This switch makes all python packages in the global system available to the virtual env.
Also check that after activating the environment your powershell indicates that you are actually using the virtual env. This is indicated by (env_name) at the beginning of the new power shell line.
I've been told that to activate a Virtual Environment in Django for Windows I should try:
environment_path\Scripts\activate
But when I enter that, cmd returns this error:
The system cannot find the path specified.
I created the virtual environment by entering:
python3 -m venv env
However when I try env\Scripts\activate I get the error described.
Can anyone help? Thanks.
Activating a virtual environment on Windows depends on where you are running it from. From the Windows Command Prompt, the command is:
environment_path\Scripts\activate.bat
If the Git-Bash shell is being used, which adds several useful tools and a more Unix/Linux-like environment, then the command is:
source environment_path\Scripts\activate
I have found the prerequisites section of Test-Driven Development with Python aka "the Testing Goat book" to be handy in getting Django, Python and related things setup on Windows.
You can create virtual environment in windows as:
py -m venv myenv (Here myenv is the name that users give. It can be anything you want)
Now to activate your myenv virtual environment type:myenv\scripts\activate
To deactivate virtual environment simply type:
deactivate
If you are using windows 7, then try environment_path\Scripts\activate.ps1
Also, error is saying, The system cannot find the path specified., make sure your path is correct.
Remember scripts folder is in your virtualenv folder.
Using Python 3.7.0 on Mac. Trying to use venv module that was added post python 3.4.
I setup my virtual env using python3 venv -m path/to/my/dir - my question is do I need to activate this virtual env to use?
The documentation seem to imply I don't need to?
You don’t specifically need to activate an environment; activation just prepends the virtual environment’s binary directory to your path, so that “python” invokes the virtual environment’s Python interpreter and you can run installed scripts without having to use their full path. However, all scripts installed in a virtual environment should be runnable without activating it, and run with the virtual environment’s Python automatically.
If I don't have to activate, what is the benefit of prepending venv to binary directory? Wouldn't this have to happen regardless for a venv to work?
Activating the virtualenv gives you convenience. It is never required.
Even for scripts that are configured to run with #!/usr/bin/env python, (which looks up the python executable on your path), you could manually update the PATH environment variable:
$ PATH="/path/to/venv/bin" some_script
Activating makes the PATH update stick until you deactivate again, and that can be convenient.
For example, I regularly have several virtualenvs in use at any one time. Some of them are there only to install some command-line tools I have symlinked into my ~/bin/ directory, another is home to a Jupyter notebook, and 2 more are used to quickly verify code snippets in different Python versions with access to 3rd-party libraries. I don't activate any of those.
When you don’t activate a virtualenv, all that happens is that your terminal PATH variable is not updated to put the bin directory of the virtualenv first, so when you enter python or pip or other script without any path into the terminal, the shell will find a different Python binary to run. You can always use any of the commands in the virtualenv bin/ directory by giving the full path to that command.
I am working in the environment when activate the ll_env
me at me in ~/desktop/django/learning_log
$ source ll_env/bin/activate
(ll_env)
me at me in ~/desktop/django/learning_log
$
When change to the parent directory, it still is in the scope of the virtual environment:
(ll_env)
me at me in ~/desktop/django
$
I assumed that ll_env might disappear when jump out of the directory where environment files lives
How Django enable the environment global?
It is not the present working directory that determines your environment. To jump out of the virtual environment, you need to deactivate it.
Using the command: deactivate
It may seem unintuitive at first, but it's important to understand that the current directory is not related to the active virtualenv. The active virtualenv determines where python should look for installed dependencies, and where it should install new dependencies to. It places that directory on your path, which is all that really matters in the context of working with a given virtualenv.
This means that you can cd anywhere on your system, do a pip install foo, and know that foo will be installed to a known location for the current venv, not to the directory you happen to be sitting in right now.
virtualenv and virtualenvwrapper give you access to a function called deactivate to stop using the virtual environment.
$ deactivate
It's different with Anaconda environment, You will deactivate it with two-word command:
$ source deactivate
When I run source bin/activate , the virtual environment seems to be activated since I can see (venv). However when I run which python , I realise its using the system wide interpreter i.e /usr/bin/python and therefore any modules in install are installed system wide. I created the virtual environment using Pycharm and when I my scripts through Pycharm, it works fine. But right now I need to run them through terminal and therefore I need the virtual environment.
To create virtualenv $ virtualenv env && source env/bin/activate then which python would show the right python here. You only need care while doing this. Sometimes you have to remove completely the env, close and restart the terminal and even source deactivate. Those are options. Virtualenv guide
EDIT:
There is no need to source deactivate. Deactivate is enough