With virtualenvwrapper, one can install "hooks" that can be run, say, after a virtualenv is activated.
I suspect not, but wanted to confirm.
No, there currently isn't such a thing.
You can patch conda's activate script directly. But your changes will be overwritten whenever you update conda. Here's an example that changes to a directory in your $HOME based on the environment name:
echo 'cd "$HOME/code/$1"' >> "$(which activate)"
Unfortunately this will only work if you use the old-school activate command:
source activate project_name rather than conda activate project_name
Related
I have pip installed powerline-shell in my base conda env. Switching envs yields the following error:
conda activate <env_name>
-bash: powerline-shell: command not found
I also tried running conda init powershell but it took no actions.
I have miniconda3, with conda 4.7, installed on MacOS Mojave.
I don't know a simple solution to this. I'm thinking you either need to install it in every env (which I don't recommend because it's best to avoid using pip in Conda) or you create a link to the powerline-shell binary in another location that you can keep on PATH to avoid adding the entire miniconda3/bin/ directory to PATH. I've done something like this in the past, but never with a Python entry point before.
I'd try something like
mkdir -p ~/.local/bin
ln -s /your/path/to/miniconda3/bin/powerline-shell ~/.local/bin/powerline-shell
Then add .local/bin to PATH in your .bashrc, probably toward the beginning (e.g., before the Conda section). The path here (~/.local/bin) is totally arbitrary, so adjust to your preferences. Main point is to minimize what you are exposing globally in a shell session.
Note: conda init powershell is for Windows PowerShell users.
As the title says I was messing with Visual Studio Code while I was checking the debugging functionality.
I obviously did something wrong because since then every new terminal I open, both on VSC and Ubuntu terminal opens with (base) environment
Any ideas how to fix it?
Somewhere you have run conda init, which adds an entry to your .bashrc file to automatically activate the base environment whenever you start a bash terminal.
If you want to undo this change completely, you can run:
conda init --reverse
However, this will mean that you can't run conda activate, for example.
If you just want to prevent conda from activating the base environment when you start your shell session, you can run:
conda config --set auto_activate_base false
This will create a .condarc file in your home directory, with an entry of auto_activate_base: false. This will override any conda defaults.
After starting my virtualenv, I would like to run a script that depends on some specifics of the environment (e.g. bash completions for some tools installed there). Is there a way to do this on a per-venv basis — effectively a local version of postactivate?
AFAIU postactivate is sourced at workon time. You don't automatically activate a virtualenv, you source bin/activate so you can add your code at the end of the bin/activate script.
To emulate predeactivate edit the same bin/activate script, function deactivate.
I'm trying to wrap my head around virtualenv and pip still.
If I use pip to install a library, it doesn't matter where I 'cd' to, because it installs the libraries in the same place right (which i dont even know where that is)? So I guess my question is, when I install something with pip, how do I make sure it only installs that library inside of my virtual environment? Do I need to cd to that directory first? or is there a command I'm supposed to use with pip to make sure it only installs to the virtualenv project I'm working in?
Activate virtualenv first:
source virt_name/bin/activate
Then after that, install the libraries:
pip install module_name
Note: Don't use sudo with pip because sometimes it will assume you want to install in /usr/local/lib/site-packages.
Generally speaking, if you do not use virtualenv --system-site-packages to create your virtualenv, you should be only working with your per-environment packages.
Providing you run the activate script before installing anything.
i.e. Do the following, if you want to install something in your virtualenv.
Run activate script
Windows: [ve_directory]\Script\activate.bat
Linux: source [ve_directory]/bin/activate
pip install [your requirements]
I think it doesn't matter where your current working directory is.
Reference:
http://www.virtualenv.org/en/latest/#the-system-site-packages-option
When you create a new environment with virtualenv, among other things it creates a bash script venv/bin/activate (where venv is the folder you specified when you created the environment; libraries are located there as well, by the way). When you run it in your shell the environment variables become arranged so that pip installs new libraries in this environment's folder. See virtualenv docs for details, section "activate script".
I use virtualenv to maintain environments for projects locally. I also use virtualenvwrapper, so I can switch between environments using
workon project1
However, when using virtualenv, you need your virtual environment to be active. I've just installed virtualenv on an ec2 instance, but how can I make sure the environment stays active? My best attempt at doing this right now is just putting the proper virtualenv commands in .bashrc. However, I'm exactly sure how this part all works... if the server restarts, will the .bashrc be run?
Essentially, what is the best way to keep a virtualenv always on on a production server?
"Activating a virtualenv" basically means you are changing your $PATH environment variable.
If you want to always have a virtualenv activated, prepend your virtualenv bin path to $PATH environment variable somewhere that gets executed before your commands run (~/.bashrc is an option).
Example (using ~/.bashrc):
export PATH=/path/to/myenv/bin:$PATH
(Assuming /path/to/myenv is where my virtualenv is placed)
~/.bashrc is only executed when you start a new bash shell (even after restarts). If you never start a bash shell, ~/.bashrc never gets executed.
If you want your virtualenv to be really permanent to your project, you could stuff the following two lines directly into your code:
activate_this = 'this_is_my_project/bin/activate_this.py'
execfile(activate_this, dict(__file__=activate_this))