Why Can't My Post-Receive Hook Run a Virtualenv Source Command

Why can't my post-receive hook run a virtualenv source command?

This is something of a guess, since you haven't quoted your complete post-receive hook, but I suspect that you don't have a shebang line pointing to /bin/bash at the top. Your post-receive hook should begin:

#!/bin/bash

I suspect this because if I run a strict Bourne shell, like dash, I get the same error when trying to source anything with source.

Activating a VirtualEnv using a shell script doesn't seem to work

TLDR

Must run the .sh script with source instead of the script solely

source your-script.sh

and not
your-script.sh

Details

sh is not the same as bash (although some systems simply link sh to bash, so running sh actually runs bash). You can think of sh as a watered down version of bash. One thing that bash has that sh does not is the "source" command. This is why you're getting that error... source runs fine in your bash shell. But when you start your script using sh, you run the script in an shell in a subprocess. Since that script is running in sh, "source" is not found.

The solution is to run the script in bash instead. Change the first line to...

#!/bin/bash

Then run with...

./virtualenv_activate.sh

...or...

/bin/bash virtualenv_activate.sh

Edit:

If you want the activation of the virtualenv to change the shell that you call the script from, you need to use the "source" or "dot operator". This ensures that the script is run in the current shell (and therefore changes the current environment)...

source virtualenv_activate.sh

...or...

. virtualenv_activate.sh

As a side note, this is why virtualenv always says you need to use "source" to run it's activate script.  

Terminal issue with virtualenvwrapper after Mavericks Upgrade

Try reinstalling pip and then reinstalling virtualenvwrapper (I had to go through these steps after upgrading to Mavericks):

$ sudo easy_install pip
$ sudo pip install --upgrade virtualenvwrapper

How do I activate a virtualenv inside PyCharm's terminal?

Edit:

According to https://www.jetbrains.com/pycharm/whatsnew/#v2016-3-venv-in-terminal, PyCharm 2016.3 (released Nov 2016) has virutalenv support for terminals out of the box

Auto virtualenv is supported for bash, zsh, fish, and Windows cmd. You
can customize your shell preference in Settings (Preferences) | Tools
| Terminal | check Activate virtaulenv

you also need to make sure to have the path of virtual environment path included in the content root folder of your project structure. You can go to settings (preference) | project | Project Structure | if your environment is not included in the project directory.

---

***Old Method:***

Create a file .pycharmrc in your home folder with the following contents

source ~/.bashrc
source ~/pycharmvenv/bin/activate

Use your virtualenv path as the last parameter.

Then set the shell Preferences->Project Settings->Shell path to

/bin/bash --rcfile ~/.pycharmrc

Getting a python virtual env error after installing Lion

I am a complete Python/Virtualenv novice. However, I had the exact same problem and found a solution that worked for me. I believe that this will vary greatly depending upon the way you originally setup Python & Virtualenv.

In my case, the Lion upgrade completely wiped out all contents of my /Library/Python/2.*/site-packages, but left the now broken executables (which link to the contents of this folder) in /usr/local/bin. I believe that this is the root cause of the cryptic "No module" import errors.

Reviewing my .bash_history, I had originally used easy_install to install pip, and then pip to install virtualenv and virtualenvwrapper. Once I repeated these steps, then I was able to re-enter my old virtual environments which still contained all the packages I had installed on 10.6. Note, however, that 10.6 shipped with Python 2.6 as default. If your packages require Python 2.6, you should change your default Python version to 2.6 first.

Step-by-step:

1. I removed old Virtualenv configuration commands from my shell startup scripts (eg., .bash_profile). Start a new terminal session.
2. (optional) Choose the version of Python you wish to use, eg.,
   
   defaults write com.apple.versioner.python Version 2.6
3. sudo easy_install pip. It seems as though /Library/Python/2.*/site-packages now requires administrator privileges. I don't recall that being the case in 10.6 (or at least my bash history doesn't reflect that).
4. sudo pip install virtualenv
5. sudo pip install virtualenvwrapper
6. Finally, I re-enabled those virtualenv configuration commands I disabled in step 1. A new terminal session had everything back the way it was (look at pip freeze -l to see local packages in this virtual environment). I think.

Broken references in Virtualenvs

I found the solution to the problem here, so all credit goes to the author.

The gist is that when you create a virtualenv, many symlinks are created to the Homebrew installed Python.

Here is one example:

$ ls -la ~/.virtualenvs/my-virtual-env
...
lrwxr-xr-x  1 ryan staff   78 Jun 25 13:21 .Python -> /usr/local/Cellar/python/2.7.7/Frameworks/Python.framework/Versions/2.7/Python
...

When you upgrade Python using Homebrew and then run brew cleanup, the symlinks in the virtualenv point to paths that no longer exist (because Homebrew deleted them).

The symlinks needs to point to the newly installed Python:

lrwxr-xr-x  1 ryan staff   78 Jun 25 13:21 .Python -> /usr/local/Cellar/python/2.7.8_1/Frameworks/Python.framework/Versions/2.7/Python

The solution is to remove the symlinks in the virtualenv and then recreate them:

find ~/.virtualenvs/my-virtual-env/ -type l -delete
virtualenv ~/.virtualenvs/my-virtual-env

It's probably best to check what links will be deleted first before deleting them:

find ~/.virtualenvs/my-virtual-env/ -type l

In my opinion, it's even better to only delete broken symlinks. You can do this using GNU find:

gfind ~/.virtualenvs/my-virtual-env/ -type l -xtype l -delete

You can install GNU find with Homebrew if you don't already have it:

brew install findutils

Notice that by default, GNU programs installed with Homebrew tend to be prefixed with the letter g. This is to avoid shadowing the find binary that ships with OS X.

Do we need to upload virtual env on github too?

As was mentioned in a comment it is standard to do this through a requirements.txt file instead of including the virtualenv itself.

You can easily generate this file with the following:
pip freeze > requirements.txt
You can then install the virtualenv packages on the target machine with:
pip install -r requirements.txt

It is important to note that including the virtualenv will often not work at all as it may contain full paths for your local system. It is much better to use a requirements.txt file.

---

Related Topics