Again - so sorry to be slow to get back to you. Would you mind updating the README to say that env_vars.sh also applies to the test phase?

@anthrotype Are you sure it's going to be specifically env_vars.sh? The variables for test are probably going to be different than the variables for build.
It could be shared if there was a way for the code to distinguish which phase is currently running...

Then, for the advertized TOXENV use case, you'll need to somehow "know" about the outside variables anyway since you're going to set TOXENV conditionally.

So, I suspect that using the functionality as suggested is going to be really awkward.

It would very much help if you override some of Multibuild's functionality privately in your repo (by sourceing additional code after them or appending to its files on the fly) to demonstrate how you envision the use cases.

Hi! I'm afraid I won't have time to work in this, but feel free to use/discard/continue as you see fit. Sorry, thanks!

I guess we could just add a test_vars.sh equivalent. Then it would be good to allow a build_vars.sh file instead of / as well as an env_vars.sh.

Well, yes, but I don't see a use case for a separate script file here.

The purpose of env_vars.sh as a separate script is to customize input to the stock Multibuild logic that runs in the container before the user's script gets control.

But in the case of testing, there's no stock logic to speak of: all it does is source a library script which doesn't make any changes.

So there's nothing it can do that config.sh or install_run() cannot.
Besides, being run before the stock logic, it can't take advantage of Multibuild's utils library.

So AFAICS at this point, it's going to confuse users and do more harm than good.
Maybe later, if/when the testing container picks up some stock machinery as Python's build system evolves...

Ok to close this one?

Closing. Please reopen if a use case arises.