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

Stephan Obermann stephan.obermann at gmail.com
Wed Jun 10 01:47:30 PDT 2015


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.

/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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20150610/278989bb/attachment.html>


More information about the testing-in-python mailing list