Running virtualenv to set the ENV

Cameron Simpson cs at
Wed Apr 24 21:39:22 EDT 2019

On 24Apr2019 16:50, Rich Shepard <rshepard at> wrote:
>>Can be either way. What I do is "python3 -m venv env" in the app
>>directory, which creates a subdirectory called "env". (I also have some
>>bash integration that means that any time it sees a directory called
>>"env", it auto-activates that venv.) So the venv is inside the app (and,
>>of course, mentioned in .gitignore).
>Thanks for sharing your approach. Rather than use the built-in venv I
>installed virtualenv in the project's root directory (and added bin/,
>include/, and lib/ in .gitignore).
>While it's working (I activate it when ready to work on the code and
>deactivate it when done), I'm still struggling to figure out the proper
>syntax to import a module that's in another package.

Personally, I like to treat the virtualenv as a source for third party 
modules needed by the project. I explicitly do not like to pollute it 
with project code - that way revision control can ignore the whole venv 
tree and it can be blown away/rebuilt freely.

So my project setup looks like this:

    venv/       virtualenv in here
    lib/python  project Python code
    foo -> lib/python/client/foo    convenience symlink
    bin/        project scripts

So, what are these pieces for?

  This is a short shell script to set up the environment to run things 
  from the project. I've got a command "env-dev" to source this; it is a 
  script with a little intelligence to locate the file, etc.  
  Having found it, it sets $ENV_DEV_DIR to the directory containing the file (i.e. the poject root) and sources 
  "$ENV_DEV_DIR/", then runs a command. Witout a command it 
  recites some important envvars like $PATH and $PYTHONPATH. I've got an 
  alias "dev=env-dev". It contains something like this:

    . $ENV_DEV_DIR/

  so the command:

    dev python -m ...

  uses the venv python (and thus the venv library) and also finds the 
  client libraries because of $PYTHONPATH above.

  Note: I do not source venv/bin/activate; it's outstandingly complex 
  and seems basicly for hacking the interactive shell to show the use of 
  the venv; it caused me great trouble when sourced from
  Anyway, it is envough just to invoke the python from inside the venv 
  (done by modifying $PATH above) - all the venv/bin executables know to 
  use the venv.

  This is local or private settings for the dev environment. Things like 
  S3 credential environment variables, or DEBUG=1 to trigger some debug 
  modes in the code, etc. gets revision controlled; is ignored.

  The virtualenv, usually containing only pip installable third party 
  modules. Ignored by revision control.

  Periodically I run "pip freeze >venv-requirements.txt"; this file is 
  revision controlled. That way I can rebuild an equivalent venv 
  somewhere else later.

  The local python code, which I'm working on.

  Whatever local convenience scripts exist.

  Convenience symlink to the client "foo" code; I can edit or run 
  "foo/whatever", etc.

Cameron Simpson <cs at>

More information about the Python-list mailing list