[pre 2.4.0] envdir being set to nothing is dangerous

[ashleywaite]

I was trying to work around the no-defaults and no-negatives reality of factors, when I managed to nuke my project directory. I suspect this isn't intended behaviour!

Have an envdir set with factor conditionals; when none of them are provided the envdir appears to be set to nothing, resulting in tox deciding that the right place to make the environment is right here where the tox.ini lives.

This results in the whole directory being blown away when it diligently tries to create the environment. Ironically blowing away the very tox.ini that tells it what to do.

Did a little search in issues and didn't see it mentioned, so figure this is either
A. Unintentional behaviour no one else was silly enough to trigger yet, or
B. An important undocumented feature for the CIA. (This program will self destruct upon execution!)

I'd suggest an interactive warning or a hard fail if envdir ends up being the same dir as tox.ini, because I simply can't imagine any circumstances where this would be intentional behaviour and it's very destructive. (Sorry CIA if you rely on this for your secure distribution). ;)

Some other suggested changes like default factors, allowed envs, etc might also address this by making it impossible to make such a silly mistake in the first place! lol

[ashleywaite]

In my case I did something like this:

[tox]
envlist = shell
envdir = dir

[testenv]
envdir =
    factor1: dir2
    factor2: dir3

[testenv:shell]
commands = ./manage.py shell {posargs}

Then this happened:

ashley@ashley-ubuntu:~/Projects/xxx$ tox
shell create: /home/ashley/Projects/xxx
^CERROR: KEYBOARDINTERRUPT
ashley@ashley-ubuntu:~/Projects/xxx$ ls -la
total 0

Whoops!

[The-Compiler]

#352 / 3e66f01 is similar, but the case where it's empty apparently isn't caught. Setting envdir=. probably should be prevented as well.

[obestwalter]

I think it would be a good idea to have a proper look in which way people can shoot themselves in the foot. I opened an additional issue to have a closer look at this.

[RonnyPfannschmidt]

this is a common result of minimal changes to get a new feature working things that are no longer what the are named to be are perfect footguns, in particular of the hosting platform is already a arsenal of footguns ^^

[obestwalter]

@ashleywaite thanks for the hilarious report - I was so shocked that another user succesfully nuked their project repository that the humour was lost on me when reading it first. I sincerely hope that you did not lose too much of your work due to this 🙏

But now your suggestion to declare this a feature is actually growing on me. Maybe we could get tox to be featured in the Mission Impossible franchise if we can make the machine emit some smoke before nuking the project directory.

[obestwalter]

o.k. I just thought I fix this right away as I don't like being complicit in unintentionally deleting other peoples projects, but this actually is also prevented already by 3e66f01.

With your tox.ini I get:

$ tox

ERROR: venv 'shell' in /home/oliver/Dropbox/projects/tox/lab/nuke would delete project
ERROR: ConfigError: envdir must not equal toxinidir

So I am pleased to tell you that the bug is also fixed for that case already. This obviously did not help you, so you must have been using a version <2.4.

[obestwalter]

@ashleywaite closing this as this is a problem with an old release unless I got something wrong then please answer here and I'll reopen.

[ashleywaite]

You are correct, I just checked and I am on 2.3.1, which is still the version distributed from the Ubuntu repository. The fix in 2.4 appears to be exactly the behaviour I'd have expected. :)
Poor CIA though.