I am writing a Makefile and I wanna call the virtualenvwrapper command "deactivate" inside Makefile.
The anwser of this thread How to leave/exit/deactivate a python virtualenv? has a comment saying that "deactivate" command is not a binary, nor a script, it's a dinamyc alias shell created when you activate your virtualenv.
So, how can I do that?
As seen in virtualenvwrapper code, deactivate is a function that is sourced into your env when you use workon.
I think that, for security reasons, make does not give access inside Makefile to current users functions and alias. So, inside your Makefile, you should source virtualenvwrapper.sh, workon on the virtualenv you want and then you'll have access to your deactivate command.
Being axe a target you have on your Makefile and brings_axe a virtualenv you already have, you should do something like this:
axe:
source virtualenvwrapper.sh; workon brings_axe; deactivate
Related
I think I have seen others who have had this same issue, but perhaps it is due to where the Anaconda image is being run on the system ( i.e where the venv is that pip has installed)
Just a note that my processor- arch is x86, and with some older style bus and memory layout.
What's more likely is that CC environment variable is affecting pip/make/autotools.
You can view your environment variable's value by running:
env |grep ^CC=
The ~/.bashrc file itself isn't read unless an interactive shell is launched, so for those shell scripts and/or Make calls that pip uses to compile Python modules, it's not likely to be sourced, but any process spawned from a shell where the CC environment variable is set will inherit that environment variable, regardless of whether it reads ~/.bashrc.
At the top of my makefile I have this line:
SHELL := /bin/sh
which is needed for most of the commands. However, I would like to also have a make command to activate my virtual env, which is on a different path.
Here is the code that I wrote for it:
activate:
source ~/.envs/$(APP)/bin/activate; \
The problem with this is, that this just prints out what is written here, and it doesn't get executed. I read that it might have something todo with only bash knowing about source, but I can't figure out how to temporarily switch modes within the activate command.
How would I have to write this method, so that it activates my virtualenv?
It does get executed.
Virtualenv works by modifying your current process's environment (that's why you have to "source" it). However, one process cannot modify the environment of the other process. So, to run your recipe make invokes a shell and passes it your virtualenv command, it works, then the shell exits, and your virtualenv is gone.
In short, there's no easy way to do this in a makefile. The simplest thing to do is create a script that first sources the virtualenv then runs make, and run that instead of running make.
Create a file called "make-venv" like this:
#!/bin/bash
source ./.venv/bin/activate
$2
Then add this to the first line of your Makefile
SHELL=./make-venv
Now, make-venv activates virtualenv before every command runs. Probably inefficient, but functional.
You can do it by using set, which allows you to set or unset values of shell options and positional parameters:
set -a && . venv/bin/activate && set +a
I've set up Ubuntu in Windows 10 and am in my home directory:
/mnt/c/Users/Me$
I want to end up in my environment directory and have it activated.
I created a file called goenv.sh in this directory and it contains:
#!/bin/bash
source environments/my_env/bin/activate
I changed the permissions of goenv.sh then tried to run it with:
./goenv.sh
...but nothing happens. What am I missing?
The script ./goenv.sh runs in a sub shell. That means that all environment changes are local to that sub shell but have no impact on the calling shell (the shell where you started it).
You need to define a function in your .bashrc to achieve that:
function goenv() {
cd environments
source my_env/bin/activate
}
Anyhow, that looks like a Python virtualenv. I recommend to install virtualenvwrapper which comes with handy shell functions to work with virtualenvs. Having it installed, you just run:
workon my_env
It works now. I changed the script shown in my question to:
#!/bin/bash
cd environments
source ./my_env/bin/activate
I'm new to bash and my Mac (about a week) and only 3 months into programming. I've been running into this problem where it ends up being something in my bash profile.
Like changing environment variables in my python so commands like
PATH="/Applications/Postgres.app/Contents/Versions/9.4/bin:$PATH”
export DATABASE_URL=“postgresql://localhost/CHEESE”
export APP_SETTINGS=“config.DevelopmentConfig"
or to get my Postgres in python to work I have to do this
export PATH=/Applications/Postgres.app/Contents/Versions/9.3/bin/:$PATH
recently I just installed virtualenvwrapper and had to do a sudo pip install virtualenvwrapper and running the code in bash would not find it unless I did this
export WORKON_HOME=$HOME/.virtualenvs
source /usr/local/bin/virtualenvwrapper.sh
So I did some research and I THINK I can permanatly add them to my 'bash profile'. If this is the case I have 2 questions.
Is there a way I can avoid having to manually add the exports in the first place. So I can have the commands working right after installing
How do I add them to my profile. I opened my .bash_profile.swp and it looked intimidating so I didn't touch it because I thought I'd break it. I'm not sure why I had a random pathing for my psycopg2 at the end of the line either( seen in the second link)
http://imgur.com/jedEOn9
http://imgur.com/CYsgVmx
You are correct. Adding these to your .bash_profile will set the environment variables every time you start up your shell. However, as explained here, it is better to put them in your .bashrc and then source that from your .bash_profile. For example,
# put this in your .bashrc
PATH="/Applications/Postgres.app/Contents/Versions/9.4/bin:$PATH"
export DATABASE_URL="postgresql://localhost/CHEESE"
export APP_SETTINGS="config.DevelopmentConfig"
# etc...
# then put this in your .bash_profile
if [ -f ~/.bashrc ]; then
source ~/.bashrc
fi
This ensures the variables are properly set no matter how you start your shell. The .swp file you are seeing is created by Vim. Just ignore it.
However, there is a better way. The easiest and cleanest way to install software on your computer is with a package manager, which will automatically set the paths for you (among other things). For Mac, I recommend using Homebrew. Once you install it, you can do things like
$ brew install ruby
$ ruby blah blah blah # ruby gets put in the PATH for you!
For python, the standard package manager is pip, which you are already using. However, a word of advice: sudo pip installs packages for the python 2 that comes as part of OS X, which from personal experience I recommend not doing. Instead, install python 2 with Homebrew, and then use the pip (and the python) that comes with that.
Inside every virtualenv of mine, I add a directory named run, this is where i put running pid files and logs, etc. I noticed that postmkvirtualenv can help me make sure this always happens when I create a new virtualenv but im not sure how to implement. I would say mkdir $VIRTUAL_HOME/$VIRTUALENV/run but $VIRTUALENV is not available... I know it's possible, just not sure how.
You probably want to use the $VIRTUAL_ENV variable instead.
Example postmkvirtalenv:
#!/bin/bash
mkdir "${VIRTUAL_ENV}"/run
The variable is quoted to protect against spaces in the path.