On Thu, Apr 25, 2019 at 11:40 AM Cameron Simpson <c...@cskk.id.au> wrote: > > 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.
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 -- https://mail.python.org/mailman/listinfo/python-list
