`[testenv]` `install_command` is also used for provision environment

[oakkitten]

From #2427. If I specify a high minversion or requires, a provision environment is created. Apparently, it is using install_command from [testenv] section. Is this right? I thought that testenv means test environment and will not be used for anything else.

If this is correct behavior, perhaps document it? Also document the way to make provision environment not use test environment. Apparently, this works:

[testenv:.tox]
install_command = python -m pip install {opts} {packages}

[testenv]
install_command = your_custom_command

Moved to discussions

P.S. Why is it necessary to specify the full env name in a section? As in, why require this: [testenv:my-cool-env] but disallow this: [testenv:cool] or [testenv:!.tox]?

Moved to another issue

Also, documentation for install_command says,

Note: You can also provide arbitrary commands to the install_command.

I don't think this is correct? Using this configuration, and running with -vvvr, I only see the first install command being executed:

[tox]
skip_install = true
skipsdist = true
envlist = foo

[testenv]
install_command =
    echo '!!!!!!!!!!!!!!!!!!!!!!! install 1' {packages}
    echo '!!!!!!!!!!!!!!!!!!!!!!! install 2' {packages}
commands =
    echo '!!!!!!!!!!!!!!!!!!!!!!! test' {envname}
deps =
    zoo

If install_command only accepts one command, perhaps fail if there are many? And the documentation shouldn't say it accepts commands?

This should probably be elsewhere

Finally, I want to note that this is not an error:

install_command =
    echo '\
    ' {packages}

And this is also not an error:

install_command =
    foo: echo '\
    ' {packages}

But this is fails:

install_command =
    foo3: echo '\
    ' {packages}

File "/usr/lib/python3.8/shlex.py", line 191, in read_token
raise ValueError("No closing quotation")
ValueError: No closing quotation

[jugmac00]

Thanks for your detailed report.

Would you be so kind and split this one into this one into four separate issues/questions? It would be much easier to handle for us.

1. I would suggest to keep this issue here, but only for the requires/minversion issue.

2. For the question about the env matching heuristics, please create a discussion if you are interested in the background, or a feature request (issue) if you want this changed.

3. Create a anotther issue for the documentation issue, about "arbitrary commands"

4. I am not sure what to do with this one, as I do not see a difference between example 2 and 3. If there is one, please create an issue and also add some text what is different so it is easier to note.

Again, thanks again for your report!

[oakkitten]

Points 1, 2, 3 done. As for 4, the difference between examples 2 and 3 is that 2 says foo and the 3 says foo3. Probably the number bit is not an issue in tox 4 anymore, but the behavior is still weird. I'll leave a comment in the appropriate issue.

[gaborbernat]

This is by design and in some cases expected (e.g. if you use install_command to set a custom PIP index, if this wouldn't be the case creating the provisioned environment would not work). The testenv name confusion I guess comes from our earlier decision to reuse test environment creation to create the provisioned tox environments. I agree we should document this under some tutorial question 🤔 @jugmac00 do you think that's where this would belong in https://diataxis.fr ?

[jugmac00]

This is by design and in some cases expected

Let's quickly talk about that.

I do think it is a bit surprising, that setting an install command for a testenv, which in my eyes is a subordinate thing to the tox section, influences how tox gets provisioned. It kinda would make more sense that it does not influence the provisioning, and in the case of using a custom PIP index, you would need to set the install command in the tox section.

But I think using a custom install command + the need to provision tox is a rare condition, otherwise this would have been reported much earlier. So I think we can keep it that way, but we should document it.

do you think that's where this would belong in https://diataxis.fr/ ?

I think the best and most pragmatic place for documenting this "kinda" surprising behavior is the install_command. I would add another "note" box.
https://tox.wiki/en/latest/config.html#conf-install_command

a la ... "Please note that the install_command will also be used when provisioning tox".

I would possible also mention it both for https://tox.wiki/en/latest/config.html#conf-minversion and https://tox.wiki/en/latest/config.html#conf-requires - that is some kind of duplication, but I think this is necessary and we do that duplication already for the --no-provision flag at both mentioned options.

I would not create a dedicated documentation for this.

[gaborbernat]

Let's quickly talk about that.

I do think it is a bit surprising, that setting an install command for a testenv, which in my eyes is a subordinate thing to the tox section, influences how tox gets provisioned. It kinda would make more sense that it does not influence the provisioning, and in the case of using a custom PIP index, you would need to set the install command in the tox section.

I personally don't find it surprising, but expected 😆 and while explicitly not documented is very much implied. Also changing it would be troublesome as would be breaking change.

[oakkitten]

if you use install_command to set a custom PIP index, if this wouldn't be the case creating the provisioned environment would not work

Funnily, one of the reasons I ran into this issue was because I have an install_command with a custom index, which doesn't have the packages from requires.

[gaborbernat]

But it could be the other way around too 🤔 That being said install_command is considered deprecated, you should instead use environment variables 👍

[oakkitten]

But if it's the other way, I still have the same issue don't I? ...wait, install_command is considered deprecated? 😯

[gaborbernat]

Indeed. You can achieve most what you want for pip with env vars. And for other you're better off with custom plugin.

[masenf]

I believe this is officially fixed with #2865