On 24Apr2019 16:50, Rich Shepard <rshep...@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 <c...@cskk.id.au>
--
https://mail.python.org/mailman/listinfo/python-list
