Running virtualenv to set the ENV

[Chris Angelico]

On Thu, Apr 25, 2019 at 11:40 AM Cameron Simpson <cs at cskk.id.au> wrote:
>
> 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.

I agree. This is especially important when you work with
cross-platform code; the venv will be the only place where any
platform-specific binaries exist, so you just leave that one directory
out of source control, and recreate it with two commands (for me,
"python3 -m venv env" followed by "pip install -r requirements.txt").

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

Yeah, that's a known feature. Even if you DO use the activate script,
this feature is of value; let's say you want to run something as a
cron job or systemd script - all you need to do is use `which python3`
or sys.executable and you can be sure it'll use any active virtual
environment. Really handy when creating installer scripts.

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

Any particular reason for this name? If not, I would generally
recommend calling it "requirements.txt", as this is a minor
convention. For instance, Heroku will recognize the presence of this
file as an indication that this is a Python app, and will
automatically "pip install -r requirements.txt" as part of deployment.

Otherwise, I broadly agree with your directory structure (although I
won't bother with a lib/python directory most of the time).

ChrisA