[feature] Provide ability to disable generation of aggregated env files

[System-Arch]

What is your suggestion?

We are using the Conan 2 install command with the --generator and --deployer options to integrate Conan-created/managed packages into an existing build system. More specifically, we use multiple instance of the install command to install packages as they are needed during the execution of a large component-based build where each component has distinct Conan package dependencies.

We specify the --output-folder to be the top of our build tree and augment that path in the generator and deployer functions to avoid collisions / race conditions. The issue that we are encountering is that these multiple "conan install" invocations all try to write aggregated env files into this top-level directory.

It appears that the most common reason that aggregated env files are being written at all is that we use shared libraries and these env files are trying to set or unset LD_LIBRARY_PATH pointing to locations in the Conan cache. Since we are using our custom deployer to copy these shared libs into the appropriate locations within our build tree (where our build system knows how to find them), the aggregated env files become completely unnecessary. Thus it would be nice if there was a way to suppress their generation, perhaps with something like:

conan install --requires <some_package> --deployer my_deployer --generator my_generator --no_aggregate_envs

Alternatively, if there is already a way to do this, that would be great too. Thanks

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[memsharded]

Hi @System-Arch

If you are using a conanfile.py (recommended for most cases), it can be disabled by:

def generate(self):
     VirtualBuildEnv(self)
     VirtualRunEnv(self)

With no call to .generate() Alternatively (I think it is not documented yet), it is possible to set the class attributes as virtualbuildenv = False and virtualrunenv=False.

[System-Arch]

Hi @memsharded, Thanks for the pointers. Indeed, using a nearly empty conanfile.py to specify the value of "requires" rather than passing it as a command line argument and setting virtual[build|run]env to False appears to have the desired effect. I did find that I needed to define "settings" in my conanfile.py in order for the settings specified in my profiles to be accessible in the generator and deployer methods--is this to be expected or should all of the profile settings be inherited regardless of what is declared in the conanfile.py?

Also, I discovered the updated migration guide (https://docs.conan.io/en/latest/conan.pdf), which appears to be a treasure trove of useful info. In this document, it talks of a configuration setting:

tools.env.virtualenv:auto_use=True

It appears that this setting is not supported in Conan 2.0, but an alternate suggestion here would be to support it in Conan 2.0 with an option to set it to "False" to achieve the desired effect. In our case, we are using a separate profile for deploying packages than for building them as we recognize the need for the virtual envs during the package creation process. In our case we are trying to keep these operations separate for better artifact management/control and are leveraging Artifactory as the intermediary. Thanks.

[memsharded]

Hi @System-Arch

Sorry this was not properly closed. this was implemented a couple of releases ago, with a new --envs-generation=false command line argument.

Closing as implemented, thanks for your feedback!