I have some noob level virtual environment questions. I've been using virtual environments a little but still have a few questions.
I have created and activated an env which is my main working environment as follows:
virtualenv env
source /path/to/environment/env/bin/activate
Having activated this, I can now see I am in the environment as I have (env) visible on command line.
My first question is, do I need to run the activate command each time I open a terminal session? And therefore each time I turn my laptop on, etc.?
Further, I want to create another environment that runs on an earlier version of python for testing purposes. I was intending to do it as follows:
virtualenv --python=python2.7 env-py2
source /path/to/new/environment/env-py2/bin/activate
Can these virtualenvs be switched easily? So can I activate env-py2 and then easily jump back to activate env again? Or is there an inbetween step required?
Apologies for the very basic questions but I was struggling to find high level information.
Yes you need to run activate command i.e. source each time you open a terminal session.
Switching between two virtual environment is easy. You can run deactivate command and source the other virtual environment.
Related
On my server (digitalocean droplet), when I activate my virtual environment, it seems something is not working. I say the because:
It does not give me the virtual environment name inside paranthesis on the command line
When I run deactivate commend, it says deactivate: command not found
user#django-s-1vcpu-2gb-sfo3-01:~/example$source env/bin/activate
user#django-s-1vcpu-2gb-sfo3-01:~/example$
running source env/bin/activate should output the following command line:
(user) user#django-s-1vcpu-2gb-sfo3-01:~/example$
I did check which folder I am at and if the env virtual environment is shown under that folder. I also looked at this point, and when I go to python manage.py shell and type those lines of code, it says I am not in the virtualenv! So, why is that? and how to fix it without completely mess up my live production site?
I just recreated the virtual environment using virtualenv env. I was reluctant to do so fearing making more problems with my live production site, but it looks OK so far. I will update if this solution has unintended consequences down the road.
Although I'm enjoying developing in Python in Visual Code, I'm finding managing virtual environments and packages frustrating, and particularly am struggling with installing packages in the right place. Here's my sequence of steps, and the problem I then have - I wonder if anyone could kindly tell me where I've gone wrong? Or do I really need to include the full Python path?
So first I create a new virtual environment:
I can see that this works:
I then choose to use the Python interpreter in this new virtual environment (I can't quite see why I have to do this - surely this should happen as part of the activation process - but I can live with it):
At the bottom left corner of my screen, I get the reassuring fact that I'm using the right Python interpreter:
I then install a package (I've chosen requests more or less at random):
However, this is going in my default Python location. To get it in my new virtual environment, I seem to have to include the full path to the Python interpreter:
This can't be right, although it does work - I can now see the installed package:
Can anyone help please?
Personally I haven't had luck using PowerShell (due to permissions to run PowerShell scripts) so I use Command Prompt in VS Code instead.
For PowerShell, perhaps activating your environment using Scripts\activate.ps1 will work instead. From the docs at:
https://docs.python.org/3/library/venv.html
# PS C:\> <venv>\Scripts\Activate.ps1
StackOverflowExample\Scripts\Activate.ps1
It is a bit confusing in VSCode having an interpreter selected and a different Command Prompt/Power Shell terminal used to install packages into a virtual environment.
Another confusing point is running StackOverflowExample\Scripts\activate doesn't suggest you are doing anything is wrong.
I agree with Jason Cook. activate.bat used to activate the environment in Cmd, you should take Activate.ps1 instead of activate.bat.
But you need not activate the environment by yourself. The Python extension can choose the right one to activate the environment for you when you create a new terminal.
After you select the interpreter, you need to create a new terminal. In general, we take a shortcut of Ctrl+Shift+`.
And if you want to turn off this function, you can set this in the settings.json:
"python.terminal.activateEnvironment": false,
OK, thanks to Jason/Steven I have finally got the hang of what you should be simple, but isn't. Here's what I reckon is the easiest way to create and activate a Python virtual environment in Visual Studio code. Let's say I start with the Tutorial environment active, and want to create one called ForeignHoliday (we can but dream). Start by creating the new environment in the VS Code terminal:
This creates the environment:
However, it doesn't activate it, nor does it change the default Python interpreter to use the one for the new virtual environment. You can do both of these things in one go by choosing an interpreter - click here at the bottom left of the VS Code screen:
You can now select an interpreter - your new virtual environment (irritatingly) won't be listed yet, so you'll have to find it:
Choose to find your interpreter:
Double-click on the Python interpreter in the Scripts folder in your new virtual environment (the pythonw alternative doesn't invoke a terminal window, so most people should avoid this - see this SO article):
Now press SHIFT + CTRL + ' to start a new terminal window (NOT just CTRL + ', as this switches you to an existing terminal window). You should see this:
You can now install and import packages and they will all be in the right place! I wish I'd read this answer a few days ago ...
I'm having trouble getting python in vs code to work properly. There were problems for a while (i dove right in with a workspace folder) so I decided to set up everything from scratch by starting a new project/workspace folder.
so far I've been having a few issues. The latest is this: despite creative a virtual environment as instructed on the vs code website, I can't get python to recognize that I've already installed the modules I want to use.
How do I fix this? (please see attached picture.
towards the bottom you can see that the virtual environment already has matplotlib, but python wouldn't recognize the module anyway
Create your virtual environment (e.g I used venv module to create a virtual env called TEST : $python3 -m venv TEST
From VS code go to Command Palette and type Python: Select Interpreter
And then you can choose the location of the desired interpreter (in my case the one from TEST virtual environment
You can always test your virtual environment from the terminal, e.g TEST env
Bash
From Cmd/Powershell normally you should run:
TEST\Scripts\activate.bat
I have recently switched to Atom as my IDE and I have been using Anaconda for some time (apparently wrong). I had just used a short script to open atom from a shell with my anaconda env activated (like this: conda activate dev; C:\Users\User\AppData\Local\atom\atom.exe), which did it for me.
However, this creates an unwanted shell and takes an unusual amount of time, so I want to know if there is a way to let Atom know in which env it should be.
For example, putting this
process.env.PATH = ['C:/Users/User/anaconda/bin/', process.env.PATH].join(':')
in init.coffe. But how should Atom know which env to use? Can I replicate conda activate in Atom?
Edit 1:
So I have Atom working with an Anaconda env right now (I had the path configured wrong), but right now it seems to be using packages from base, while I want Atom to use packages and python from dev. Is this possible without completely defeating the purpose of Anaconda envs by putting every environment in the PATH?
I managed to get some where with this.
I was not able to start Atom via launching it whilst in a conda virtual env or virtualenv which was quite frustrating.
But if you are using the __platform-io IDE terminal__, you can very easily configure the Terminal to start in a conda virtual env.
If you head over to the packages tab once you have it installed, then:-
1) Core settings - > **Shell Override**: enter *C:\Windows\System32\cmd.exe*
2) **Auto Run Commands** -> enter command to activate conda venv e.g. *conda activate activate nlp_tf*
This will then automatically start your Conda virtual environment (in this example _nlp_tf_) with each terminal load.
Hopes this helps
(Now I am trying to figure out how to integrate Hydrogen into this- if anyone knows, please don't hesitate.)
This is a total newbie question, but I installed conda along with a bunch of other stuff like Tensorflow with a virtual environment, and now I'm a little confused. If I open a terminal my python is pointing to /usr/bin/python. If I go to the base environment ("conda activate base"), my path points to where I installed anaconda, /usr/local/anaconda2. Does conda expect that I always go into the base environment to use all the anaconda packages, or did I do something weird on my install that my non-environment still points to the original system python? Should I just change my path to point to anaconda? I'm on Ubuntu 18.10.
I am a fan of being explicit -- instead of running python at the command line, I use the full path to the python interpreter when running scripts (e.g. /usr/local/anaconda2/bin/python) -- this way I don't rely on the shell behavior or having to worry about which environment is currently active. Running the interpreter using its full path is no different than just running python while the environment is active.
But that's not everbody's cup of tea... So...
Even if anaconda did not prompt you to update your PATH variable, you can do it explicitly by updating your .bashrc or .bash_profile (or .zshrc or whatever else) by adding this line: PATH=/usr/local/anaconda2/bin${PATH}. Dont forget to re-source the .bashrc or close/reopen your shell for it to take effect.
Conda is capable of creating many virtual environments beyond the base, so if you have more than one and you want to set one as the default, then just update the line above for the appropriate path.