On 16Jun2017 06:40, Tim Chase wrote:
At least within virtualenvwrapper (I'm not sure whether they come
with virtualenv proper), in my $WORKON_HOME and
$WORKON_HOME/$VIRTUALENV/bin directories, I have a bunch of pre* and
post* templates including preactivate and postactivate hooks in which
I can
On 2017-06-16 15:53, Ben Finney wrote:
> > I must admit my initial preference would be the differently named
> > wrapper. Surely users of the codebase will be invoking stuff via
> > something opaque which sources the requisite things?
>
> That “something opaque” is the ‘$VENV/bin/activate’ scrip
Cameron Simpson writes:
> I must admit my initial preference would be the differently named
> wrapper. Surely users of the codebase will be invoking stuff via
> something opaque which sources the requisite things?
That “something opaque” is the ‘$VENV/bin/activate’ script; many people
who join t
On 13Jun2017 11:57, Ben Finney wrote:
Many of the code bases for which I use a Python virtualenv, need
additional (custom) environment variables set, each time the virtualenv
is activated.
How can I make this easy for developers who already know how to activate
a virtualenv?
* Edit the ‘$VENV/
Howdy all,
What is the conventional way to customise the changes made by a Python
virtualenv bin/activate script?
The Python virtualenv is activated by a ‘$VENV/bin/activate script’ [0].
This script works primarily by setting environment variables specific to
the virtualenv.
(This is different
