[bug] The new VirtualRunEnv never clean the deactivate script (it should use a temp deactivate file)

Environment Details

• Operating System+version: Linux (archlinux)
• Conan version: 1.47.0
• Python version: 3.9

Steps to reproduce (Include if Applicable)

conanfile.txt:

[requires]
fmt/8.0.0
# testing only deps below
doctest/2.4.6

[generators]
CMakeToolchain
CMakeDeps
VirtualRunEnv

$ conan install . --install-folder=.conanvirtualenv --build=missing --profile:build=default
$ source .conanvirtualenv/conanrun.sh
Capturing current environment in .conanvirtualenv/deactivate_conanrunenv-release-x86_64.sh
Configuring environment variables
$ source .conanvirtualenv/deactivate_conanrun.sh
Restoring environment
$ source .conanvirtualenv/conanrun.sh
Capturing current environment in .conanvirtualenv/deactivate_conanrunenv-release-x86_64.sh
Configuring environment variables
$ source .conanvirtualenv/deactivate_conanrun.sh
Restoring environment
Restoring environment

Explanation of the issue

The issue here is, the more we do activate/deactivate the more the string “Restoring environment” will be displayed (and after a while it can be very annoying on my shell) and the more the script deactivate_conanrunenv-release-x86_64.sh will be full. When using the VirtualRunEnv I found that very annoying after a while. I would recommend that:

• the activate script create a temp deactivate file with mktemp
• stores the place of the deactivate file in the env variable CONAN_DEACTIVATE_FILE
• source $CONAN_DEACTIVATE_FILE in the non temp deactivate script.

I could do a PR for linux with that, but since I don’t know how to do that on Windows (I don’t have Windows installed at all) I think my PR won’t be accepted.

@memsharded @lasote @czoido: I think you guys are the one working on this recently (so I hope it is okay to highlight you), what do you think?

[CPickens42]

I understand completely. To be honest I thought that conan 2.0 would be out in a few month at least. I will do a PR when I’ll have the time on my own (not until few weeks). I think doing it is mandatory on the long run to have a proper experience of conan.

[memsharded]

Ok, thanks very much for the detailed explanation.

Now I understand the issue, I thought we were talking about multiple sequential activation & deactivation of environments. I see that we are talking about concurrent usage of these environment scripts, and it is completely true that the current approach is not designed to support it.

I agree that learning from Python virtualenvs and improving the current approach is the way to go. The only thing is that this will not be a priority at the moment as we are focusing on getting 2.0 out. I’d say to try it in the 2.X scope. Contributions are welcome, of course, but they also require time to review and to understand well what is doing (because the truth is that in the long term we need to support, maintain and evolve it).