Running virtualenv to set the ENV

Cameron Simpson cs at cskk.id.au
Wed Apr 24 21:39:22 EDT 2019


On 24Apr2019 16:50, Rich Shepard <rshepard at appl-ecosys.com> 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).
>
>ChrisA,
>
>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:

  project-foo-for-client/
    .env.sh
    .env-local.sh
    venv/       virtualenv in here
    venv-requirements.txt
    lib/python  project Python code
    foo -> lib/python/client/foo    convenience symlink
    bin/        project scripts

So, what are these pieces for?

.env.sh

  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 .env.sh file, etc.  
  Having found it, it sets $ENV_DEV_DIR to the directory containing the 
  .env.sh file (i.e. the poject root) and sources 
  "$ENV_DEV_DIR/.env.sh", 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:

    PATH=$ENV_DEV_DIR/bin:$ENV_DEV_DIR/venv/bin
    PYTHONPATH=$ENV_DEV_DIR/lib/python
    export PATH PYTHONPATH
    . $ENV_DEV_DIR/.env-local.sh

  so the command:

    dev python -m client.foo ...

  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 .env.sh.
  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.

.env-local.sh

  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.

.env.sh gets revision controlled; .env-local.sh is ignored.

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

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

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

bin/
  Whatever local convenience scripts exist.

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

Cheers,
Cameron Simpson <cs at cskk.id.au>



More information about the Python-list mailing list