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.
Related
My use case: I want to execute a script setting up a virtual Python environment prior to any configure or build step. While I can simply source this script before calling CMake on the command line, I want to be able to do the same within the CMake Tools extension without having to adapt the CMakeLists.txt files.
The extension has the cmake.environment, cmake.buildEnvironment and cmake.configureEnvironment settings. But I don't want to manually reverse-engineer the script nor maintain the list of possibly changing environment variables. I simply want to execute the script and have CMake run in the sourced context.
Short answer: Have the cmake.cmakePath point to a script that sources the original script (or calls whatever is wanted) then calls the actual CMake executable (along with forwarding all passed parameters).
Example:
#!/bin/bash
source /home/user/the_script_you_want_to_source # or whatever other script you want to have executed
/usr/local/bin/cmake "$#" # don't forget to forward the passed parameters
Note that it may be required to chmod +x the pointed-to script.
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.
Is there any way to make workon global? For example; I open terminal and type workon myenvname --global, then I open another terminal window and type something like python myscript.py and it will run it under the myenvname environment?
Also I can then open Sublime Text IDE and create a python script, then press CTRL+b and the python script will run in the myenvname environment.
Is such a thing possible?
No. Virtual environments must be activated in every shell (i.e., every terminal) separately.
There is no magic in Python virtual environments. Their activation just sets a few environment variables; the most important is PATH so that the current shell finds python and pip. Then python being run from a virtual env detects it and sets sys.path accordingly.
To some extent you can do a trick without activation: run python from a virtual env:
/path/to/venv/bin/python myscript.py
Hope it helps someone
You may not be able to run it globally but if you want to run a particular python script without entering into the virtualenv. Here's a work around.
Considering you are using this on linux.
Say you have a virtualenv called myenvname
You would like to run a particular python script myscript.py inside this particular myenvname without even using terminal by just double click on an icon.
Create a shell script myshellscript.sh
#!/bin/bash
# open the virtual environment
source /home/usr_name/.virtualenvs/myenvname
# location to the python script you want to run
# python/python3 depending on the version you are using
python location/to/your/python/script/myscript.py
Give permission for myshellscript.sh to be an executable
chmod +x myshellscript.sh
Create a .desktop file inside /usr/share/applications/
sudo nano /usr/share/applications/myscript.desktop
copy paste the block of code and make the changes accordingly
[Desktop Entry]
Version=1.0
Type=Application
Terminal=false
Exec=shellscript file to be run along with its path
Path=directory where the file is located
Name=myscript
Comment=comment here
Icon=icon path here
then give permission to the myscript.desktop
chmod +x /usr/share/applications/myscript.desktop
You are done.
Just goto /usr/share/applications/ and double click on myscript icon, you got your myscript.py running
I have a custom Makefile project in Eclipse and although the build does get run in a Cygwin shell... it does not seem to be a login shell (bash --login) as it doesn't set my environment variables like running cygwin.bat does.
Where in Eclipse can I change the shell command so that it will be a login shell?
What you actually aim with bash --login are your settings from /etc/profile.
Under UNIX you normally have only one login shell and so these settings are inherited by all other shells. Under Windows any Bash window is an isoloated login shell, which leads to missing environment settings when running Bash from tools that run bash simply as command processor.
I had a similar problem with Emacs compile feature. The best solution under Windows is to set the environment variable BASH_ENV to a script. Bash will execute this script when started without -i or --login, so that /etc/profile is not run. Hence the script will setup Bash for non-interactive, non-login shells.
Example:
BASH_ENV=%USERPROFILE%\.bash_env
as user environment variable. The least thing to do in this script is to set PATH as in /etc/profile:
PATH="/usr/local/bin:/usr/bin:${PATH}"
Check the path-settings in /etc/profile as it is created by Cygwin's setup.exe. You may also copy settings from ~/.bashrc or source this script.
Hope this helps.
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))