Running virtualenv to set the ENV
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).
>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 .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:
export PATH PYTHONPATH
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.
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.
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
Cameron Simpson <cs at cskk.id.au>
More information about the Python-list