[wip] Add environment variables to detect running from within tox (#847)

[gaborbernat]

• TOX_WORK_DIR for session runs (only this set during packaging)
• TOX_ENV_NAME and TOX_ENV_WORK_DIR during the execution of a given virtual environment
• add a section inside documentation that will focus on the high-level information about tox (for now contains the existence of this os environment variable injection).

Resolves #847.

[codecov]

Codecov Report

Merging #865 into master will increase coverage by <1%.
The diff coverage is 96%.

@@          Coverage Diff           @@
##           master   #865    +/-   ##
======================================
+ Coverage      92%    93%   +<1%     
======================================
  Files          12     13     +1     
  Lines        2331   2344    +13     
  Branches      408    409     +1     
======================================
+ Hits         2155   2169    +14     
  Misses        110    110            
+ Partials       66     65     -1

[rpkilby]

Would it also make sense to add TOX=true, so users can detect tox without depending on a more specific/functional variable? This would be analogous to how Travis sets TRAVIS=true.

[asottile]

I didn't read much after noticing this could be done today with setenv.

another concern: there'd be no way to turn it off (?)

[asottile]

should we make these consistent with the names that get substituted in the configuraiton? https://tox.readthedocs.io/en/latest/config.html?highlight=substitution#substitutions

particularly envname but ENV_NAME seems off to me

should we export all of these substitution parameters as well?

do we even need this feature? someone can setenv = TOX_ENV_NAME={envname} already today

[gaborbernat]

Although one could do it partially with the setenv as discussed in the related #847 it adds value to have a general env var name. This way the tools can use to detect if we're inside tox and users no longer need to keep copying around the same set env for their project.

Coming back to the setenv I don't think that cuts it. Mostly because setenv is only applied to the current command. I think we want a higher level to be able to be detected by both the package builder and the installer. These are also tools which we invoke; we're not talking here just about commands. In light of this can you have another look?

[asottile]

afaik setenv applies to all life cycles (I looked into this for tox-virtualenv-no-download)

[gaborbernat]

Hmmm, will double check.

[asottile]

Here's that analysis : asottile-archive/tox-virtualenv-no-download#4 (comment)

[asottile]

hmmm, seems odd that they'd get whitelisted into passenv as well -- I guess that's an order-of-operations issue probably? (depending on when the variables get set)

if we're going forward with this, can we make tox augment setenv and then we don't need to worry about passenv?

[gaborbernat]

Because I wanted these environment variables to be usable across the tool lifecycle, not just the commands section, I change the values in the os.environ. As such in order for the commands to inherit it we need them to be in the whitelist.

[gaborbernat]

@rpkilby I could see some people wanting the work dir too besides just are we inside tox (e.g. pytest-testmon). I would like to keep the injected environment variable count low, hence given the TOX_WORK_DIR already serves all the answers of a potential TOX env var, I don't think we want to add that.

[obestwalter]

I definitely like the idea of doing this - I actually could swear that I opened an issue proposing this just after I joined the project but can't find it anymore ...

Hi @gaborbernat I would really like to get my head around this PR first, so please wait for my feedback on this one. I would also propose not to add this to 3.1 yet. I think we have enough changes already to ship 3.1. We have some massive refactorings and there might be surprises, that are easier to catch, if we don't ship to many changes at once.

[gaborbernat]

Ok let's move it to 3.2. As such I'll delay working on this for later.

[obestwalter]

Was there a problem with the changes? I did not get around to check this out yet.

[gaborbernat]

I did not get around to finish this. Will re-open later on; but given it's part of 3.2 can wait for now to fix the latest release.