[TIP] RFC: tox-2.0 to restrict/isolate env variables in test runs

David Cournapeau cournape at gmail.com
Sun Jun 14 01:57:52 PDT 2015


On Fri, Jun 12, 2015 at 8:18 PM, holger krekel <holger at merlinux.eu> wrote:

> On Wed, Jun 10, 2015 at 10:47 +0200, Stephan Obermann wrote:
> > On Wed, Jun 10, 2015 at 2:38 AM, David Cournapeau <cournape at gmail.com>
> > wrote:
> >
> > >
> > >
> > > On Wed, Jun 10, 2015 at 3:28 AM, Roy Wright <roy at wright.org> wrote:
> > >
> > >>
> > >> On Jun 9, 2015, at 1:09 PM, holger krekel <holger at merlinux.eu> wrote:
> > >>
> > >> > Roy, David,
> > >> >
> > >> >> On Tue, Jun 09, 2015 at 11:14 -0500, Roy Wright wrote:
> > >> >>> On Jun 9, 2015, at 10:00 AM, David Cournapeau <cournape at gmail.com
> >
> > >> wrote:
> > >> >>>
> > >> >>> I am late to the party, and I guess it is too late, but I am not
> > >> convinced this is a good idea, at least not as a default (should be
> opt-in,
> > >> not opt-out).
> > >> >>>
> > >> >>> This breaks a lot of basic features, in a way that is fairly
> > >> complicated to debug. E.g. with tox 2.0, os.path.expanduser("~") is
> now
> > >> broken on windows because e.g. USERNAME is not propagated.
> Realistically,
> > >> way too many programs depend on various environment variables.
> > >> >>
> > >> >> If you are behind a firewall, you may need to pass in your proxy
> > >> variables so pip can connect to pypi.python.org, even if you are
> using
> > >> an internal index. I.e., tox fails to create a virtualenv. Not good.
> > >> >>
> > >> >> I'd prefer to be able to set options that affect all usages of a
> > >> utility globally instead of needing to add to every project I want to
> test.
> > >> >>
> > >> >> I can understand the need to totally control the test environment.
> > >> It's just that there are system needs that must be met before test
> needs.
> > >> >
> > >> > Would it help you if we introduce a TOX_PASSENV environment variable
> > >> > (and maybe a command line option) that is honored in addition to
> > >> > the tox.ini values?  You could set that on a per-system basis.
> > >>
> > >> I could live with that. :-)
> > >>
> > >> A list of platform examples would be nice.
> > >>
> > >> My preference would be a ~/.toxrc just because you can include
> comments
> > >> and examples.
> > >>
> > >
> > > I would prefer a .toxrc as well for the same reasons.
> > >
> >
> > ​
> > Sorry for jumping in here. Just to clarify,
> > ​would using the mechanism described above (​
> > env. variabl
> > ​e, toxrc entry and/or
> > running tox with the mentioned command line option
> > ​)​
> >  disable the "env variable isolation" feature completely? If so, I'm
> voting
> > for such a mechanism due to the huge (and unfortunately mainly negative)
> > impact that feature brought for us internally.
>
> It would be possible to have a system-wide setting (env var or toxrc)
> to disable env var isolation. Stephan, others, are the env-var
> problems with executing tests or with setting up/installing dependencies
> or both?
>

Both.

David


>
> best,
> holger
>
>
> > /stephan
> > ​
> >
> >
> > >
> > > Thank you for looking into it,
> > >
> > > David
> > >
> > > _______________________________________________
> > > testing-in-python mailing list
> > > testing-in-python at lists.idyll.org
> > > http://lists.idyll.org/listinfo/testing-in-python
> > >
> > >
>
> > _______________________________________________
> > testing-in-python mailing list
> > testing-in-python at lists.idyll.org
> > http://lists.idyll.org/listinfo/testing-in-python
>
>
> --
> about me:    http://holgerkrekel.net/about-me/
> contracting: http://merlinux.eu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20150614/2809977e/attachment.html>


More information about the testing-in-python mailing list