What happens under the hood of the mkvirtualenv command?

I am wondering what is happening under the hood of the mkvirtualenv , and therefore I am trying to understand what it calls virtualenv .

The lowest hanging fruit is the number where the virtualenv program is after installation and where the mkvirtualenv program is after installation. So: -

 Calvins-MacBook-Pro.local ttys006 Mon Apr 23 12:31:07 |~| calvin$ which mkvirtualenv Calvins-MacBook-Pro.local ttys006 Mon Apr 23 12:31:10 |~| calvin$ which virtualenv /opt/local/library/Frameworks/Python.framework/Versions/2.7/bin/virtualenv 

It is so strange that I see here that which mkvirtualenv gives no result. Why?

Digging further, in the virtualenvwrapper directory after installing it, I see only 3 python files: -

 Calvins-MacBook-Pro.local ttys004 Mon Apr 23 12:28:05 |/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/virtualenvwrapper| calvin$ ls -la total 88 drwxr-xr-x 8 root wheel 272 Apr 13 15:07 . drwxr-xr-x 29 root wheel 986 Apr 15 00:55 .. -rw-r--r-- 1 root wheel 5292 Apr 13 15:05 hook_loader.py -rw-r--r-- 1 root wheel 4810 Apr 13 15:07 hook_loader.pyc -rw-r--r-- 1 root wheel 1390 Apr 13 15:05 project.py -rw-r--r-- 1 root wheel 2615 Apr 13 15:07 project.pyc -rw-r--r-- 1 root wheel 7381 Apr 13 15:05 user_scripts.py -rw-r--r-- 1 root wheel 11472 Apr 13 15:07 user_scripts.pyc 

And I believe that the only reason mkvirtualenv now available in my terminal is because I added to source/opt/local/library/Frameworks/Python.framework/Versions/2.7/bin/virtualenvwrapper.sh . Therefore, answering the question I asked earlier, it is simply because mkvirtualenv is expressed as a bash function and is available in my terminal, because I received the virtualenvwrapper.sh file in my .bashrc or .bash_profile files.

Digging in a virtualenvwrapper.sh script, I see

 # Create a new environment, in the WORKON_HOME. # # Usage: mkvirtualenv [options] ENVNAME # (where the options are passed directly to virtualenv) # function mkvirtualenv { typeset -a in_args typeset -a out_args typeset -ii typeset tst typeset a typeset envname typeset requirements typeset packages in_args=( " $@ " ) if [ -n "$ZSH_VERSION" ] then i=1 tst="-le" else i=0 tst="-lt" fi while [ $i $tst $# ] do a="${in_args[$i]}" # echo "arg $i : $a" case "$a" in -a) i=$(( $i + 1 )); project="${in_args[$i]}";; -h) mkvirtualenv_help; return;; -i) i=$(( $i + 1 )); packages="$packages ${in_args[$i]}";; -r) i=$(( $i + 1 )); requirements="${in_args[$i]}";; *) if [ ${#out_args} -gt 0 ] then out_args=( "${out_args[@]-}" "$a" ) else out_args=( "$a" ) fi;; esac i=$(( $i + 1 )) done set -- "${out_args[@]}" eval "envname=\$$#" virtualenvwrapper_verify_workon_home || return 1 virtualenvwrapper_verify_virtualenv || return 1 ( [ -n "$ZSH_VERSION" ] && setopt SH_WORD_SPLIT \cd "$WORKON_HOME" && "$VIRTUALENVWRAPPER_VIRTUALENV" $VIRTUALENVWRAPPER_VIRTUALENV_ARGS " $@ " && [ -d "$WORKON_HOME/$envname" ] && \ virtualenvwrapper_run_hook "pre_mkvirtualenv" "$envname" ) typeset RC=$? [ $RC -ne 0 ] && return $RC # If they passed a help option or got an error from virtualenv, # the environment won't exist. Use that to tell whether # we should switch to the environment and run the hook. [ ! -d "$WORKON_HOME/$envname" ] && return 0 # If they gave us a project directory, set it up now # so the activate hooks can find it. if [ ! -z "$project" ] then setvirtualenvproject "$WORKON_HOME/$envname" "$project" fi # Now activate the new environment workon "$envname" if [ ! -z "$requirements" ] then pip install -r "$requirements" fi for a in $packages do pip install $a done virtualenvwrapper_run_hook "post_mkvirtualenv" } 

Here, where I don't understand yet - I don't see a direct link to virtualenv in this bash function. So, how exactly does this bash function mkvirtualenv pass arguments from the command line (e.g. mkvirtualenv -p python2.7 --no-site-packages mynewproject ) to the python virtualenv program?

+6
source share
1 answer

So this is the line that does the trick.

 ( [ -n "$ZSH_VERSION" ] && setopt SH_WORD_SPLIT \cd "$WORKON_HOME" && "$VIRTUALENVWRAPPER_VIRTUALENV" $VIRTUALENVWRAPPER_VIRTUALENV_ARGS " $@ " && [ -d "$WORKON_HOME/$envname" ] && \ virtualenvwrapper_run_hook "pre_mkvirtualenv" "$envname" ) 

$VIRTUALENVWRAPPER_VIRTUALENV is actually the place where the current virtualenv program is located.

In terminal

 Calvins-MacBook-Pro.local ttys004 Mon Apr 23 13:24:14 |~| calvin$ which $VIRTUALENVWRAPPER_VIRTUALENV /opt/local/library/Frameworks/Python.framework/Versions/2.7/bin/virtualenv 

Mitzeri decided.

+3
source

Source: https://habr.com/ru/post/913898/


All Articles