OSX virtualenv fixing by creating a simple alias

[nils-werner]

Added simple solution of creating frameworkpython alias. to OSX virtualenv fixing.

The alias does exactly what the script does: it runs python with a variable PYTHONHOME set. The script is a bit overkill because virtualenv source bin/activate puts the root dir of the virtualenv already in a variable $VIRTUAL_ENV. So picking this one up and running the system wide Python interpreter can be easily done in a one line alias.

[tacaswell]

attn @jenshnielsen @mdehoon

[jenshnielsen]

That is a nice solution. The only issue that I have is that calling frameworkpython outside a virtualenv will result in errors like no module named site in python 2 and a segfault in python 3. I wonder if there is a better way of solving this.

[nils-werner]

I have pushed another change that first checks if $VIRTUAL_ENV is actually set before trying to run Python. If it isn't set it will simply run Python without setting $PYTHONHOME.

[jenshnielsen]

Unfortunately that does not allow me to pass commandline arguments to the alias inside the virtualenv (it does work outside) I suggest something like:

alias frameworkpython2='[[ -z "$VIRTUAL_ENV" ]] && echo "Not running in a virtualenv use regular python" || PYTHONHOME=$VIRTUAL_ENV /usr/local/bin/python/'

Which does allow passing of cmd arguments. What do you think?

@tacaswell What do you think about backporting this to the 1.5.0-docs branch. This is a much better solution than what is in there now.

[nils-werner]

I have updated it again to use a proper bash function. It's much more
readable and works properly now.
Am 21.11.2015 9:55 vorm. schrieb "Jens Hedegaard Nielsen" <
notifications@github.com>:

Unfortunately that does not allow me to pass commandline arguments to the
alias inside the virtualenv (it does work outside) I suggest something like:

alias frameworkpython2='[[ -z "$VIRTUAL_ENV" ]] && echo "Not running in a virtualenv use regular python" || PYTHONHOME=$VIRTUAL_ENV /usr/local/bin/python/'

Which does allow passing of cmd arguments. What do you think?

@tacaswell https://github.com/tacaswell What do you think about
backporting this to the 1.5.0-docs branch. This is a much better solution
than what is in there now.

—
Reply to this email directly or view it on GitHub
#5516 (comment)
.

[jenshnielsen]

Yes that is probably better. The only thing missing for me it the ability to test if we are running python3 or 2. Perhaps this is being to clever but the following works for me.

function frameworkpython {
    if [[ ! -z "$VIRTUAL_ENV" ]]; then
        #test if we are running python 2 or 3
        pyversion=`python -V 2>&1 | cut -d ' '  -f2 | cut -d. -f1`
        PYTHONHOME=$VIRTUAL_ENV /usr/local/bin/python$pyversion "$@"
    else
        /usr/local/bin/python "$@"
    fi
}

I use virtualenvs with both python 2 and 3. This will naturally fail if you are using more than 1 python 3 version in your virtual env

[jenshnielsen]

Actually we might as well be a bit more clever:

function frameworkpython {
    if [[ ! -z "$VIRTUAL_ENV" ]]; then
        #test if we are running python 2 or 3
        pyversion=`python -V 2>&1 | cut -d ' '  -f2 | cut -d. -f1,f2`
        PYTHONHOME=$VIRTUAL_ENV /usr/local/bin/python$pyversion "$@"
    else
        /usr/local/bin/python "$@"
    fi
 }

[jenshnielsen]

We should probably also note that users might have to modify /usr/local/bin depending on where their python is installed.

We might as well also modify the script above to use $VIRTUAL_ENV rather than the python -c import os ... thing.

[tacaswell]

+1 on back porting to 1.5.0-doc

On Sat, Nov 21, 2015, 05:05 Jens Hedegaard Nielsen notifications@github.com
wrote:

We should probably also note that users might have to modify
/usr/local/bin depending on where their python is installed.

We might as well also modify the script above to use $VIRTUAL_ENV rather
than the python -c import os ... thing.

—
Reply to this email directly or view it on GitHub
#5516 (comment)
.

[nils-werner]

We can make it even more clever:

export GLOBALPYTHON=$(which python)

function frameworkpython {
    if [[ ! -z "$VIRTUAL_ENV" ]]; then
        #test if we are running python 2 or 3
        pyversion=`python -V 2>&1 | cut -d ' '  -f2 | cut -d. -f1,f2`
        PYTHONHOME=$VIRTUAL_ENV $GLOBALPYTHON$pyversion "$@"
    else
        $GLOBALPYTHON "$@"
    fi
 }

Needless to say this slowly stops being a simple, easy to understand solution :-)

[nils-werner]

@jenshnielsen Running

python -V 2>&1 | cut -d ' '  -f2 | cut -d. -f1,f2

fails with cut: [-cf] list: illegal list value but

python -V 2>&1 | cut -d ' '  -f2 | cut -d. -f1 -f2

works for me. Is there a particular reason why you picked -f1,f2?

[jenshnielsen]

Sorry that is a bug as I copied from my bash profile. I was using:

python -V 2>&1 | cut -d ' '  -f2 | cut -d. -f1,2

but

python -V 2>&1 | cut -d ' '  -f2 | cut -d. -f1 -f2

is equally good

[jenshnielsen]

Merging this now. We can always make it more elaborate

[jenshnielsen]

backported to 1.5.0-doc as 6f0e6ad