Ability to disable provisioning

[hroncok]

I was looking into redefining how provisioning works via a plugin. I was not successful, it seems that provisioning happens before any plugin code even runs. I've seen the code in tox and realized that changing it in 3.x would be very tedious.

However, I've also realized, that I don't need to redefine the behavior, all I need is to stop it from happening. Apparently, all I needed to do was to set the TOX_PROVISION=1 environment variable to get this exception:

tox/src/tox/config/__init__.py

Lines 1349 to 1351 in d5957b8

	if WITHIN_PROVISION and missing_requirements:
	msg = "break infinite loop provisioning within {} missing {}"
	raise tox.exception.Error(msg.format(sys.executable, missing_requirements))

Before I start using this as a hack:

• is this even an API?
• what are the side effects? I see that WITHIN_PROVISION is used at more places.

Would it be possible to have a documented way to error here, without side effects? I was thinking TOX_NO_PROVISION or even TOX_PROVISION=error. Ideally, the error would print the list of missing dependencies in a way that is easily parseable (with literal_eval is fine).

I can work on this, if this would be accepted. I can also go into details about why I'd like to have this if you want.

[gaborbernat]

Provisioning is meant to pull in the plugins so having a plugin that alters how you pull in plugins seems very meta. There has been no thought put into this behavior and overriding TOX_PROVISION leaves you in undefined land. Please do tell why though 👍🏻

[hroncok]

In Fedora, we use tox to run the upstream tests when we build the RPM packages. Unlike regular tox users, we don't want to install packages from PyPI to a virtual environment, because we need to test integration with other Fedora packages. We have created a plugin for our needs. More details about the use case are in the README. https://github.com/fedora-python/tox-current-env

1. We use the plugin to generate a list of requirements.
2. We install those requirements via Fedora RPM packages.
3. We use the plugin to run the tests in "current" Python environment.

This all works unless tox determines it needs provision. With provisioning, the situation differs depending on internet availability.

When online:

1. We use the plugin to generate a list of requirements.
   1. tox creates a provision environment
   2. tox fails, because our plugin is not installed into the provision environment

When offline:

1. We use the plugin to generate a list of requirements.
   1. tox attempts to creates a provision environment, it fails

What I'd like to do instead:

1. We use the plugin to generate a list of requirements with TOX_NO_PROVISION (or similar) set
   1. tox figures requires are missing, it errors with the list
   2. we parse the list
   3. we install requirements from the list via Fedora RPM packages
2. (if needed) We use the plugin to generate a list of requirements again.
3. We install those requirements via Fedora RPM packages.
4. We use the plugin to run the tests in "current" Python environment.

[gaborbernat]

I'll get back to you tomorrow on this, need to have a think about what's good approach here.

[hroncok]

Thanks. I'd also be happy to talk about it over chat or video if you'd prefer.

[gaborbernat]

Can you join discord.gg/tox?

[gaborbernat]

@hroncok if you can join Discord now 🙇🏻

[gaborbernat]

Conclusion:

@hroncok will create a PR against v3 to add a --no-provision flag that when set refuses to perform provisioning and instead raises an exception. That flag takes an optional argument to the path. If the provisioning fails, will write a JSON file to that path with:

{
"minversion": "3.2.1",
"requires": ["PEP-440"]
}

[hroncok]

#1922