On Sep 9, 7:45 pm, Christian Heimes <[EMAIL PROTECTED]> wrote:
> ago wrote:
> > The only thing I would add is that in my experience I often use
> > different working-envs for different projects, so I'd prefer to have a
> > more generic solution as opposed to a single working-env per user. The
> > l
Small variation on the above patch, using 2 environment variables:
PYTHONSITEDIR allows for local site-packages (that override system
site packages), and PYTHONNOSYSSITES skips system site-packages for
"clean-room" operation (similar to virtual-python.py --no-site-
packages).
--- /usr/lib/python2
ago wrote:
The only thing I would add is that in my experience I often use
different working-envs for different projects, so I'd prefer to have a
more generic solution as opposed to a single working-env per user. The
latter could still be achieved by setting the appropriate environment
variable i
On Sep 9, 6:56 pm, Christian Heimes <[EMAIL PROTECTED]> wrote:
> I had a similar idea, wrote a PEP and implemented it for 2.6 and 3.0:
>
> http://www.python.org/dev/peps/pep-0370/
>
> Christian
Christian,
I like your pep :),
The only thing I would add is that in my experience I often use
differ
ago wrote:
Wouldn't it be possible to support a PYTHONSITEDIR environment
variable in site.py for this purpose? I have attached a possible
patch. In what follows, if PYTHONSITEDIR is defined, that dir is used
as the only source of site-packages, extra paths can easily be added
by creating a
get close, but not quite there, and the above scripts seem
a bit over the top.
Wouldn't it be possible to support a PYTHONSITEDIR environment
variable in site.py for this purpose? I have attached a possible
patch. In what follows, if PYTHONSITEDIR is defined, that dir is used
as the only sourc
