EnvVars

EnvVars is a class that represents an instance of environment variables for a given system. It is obtained from the generic Environment class.

This class is used by other tools like the conan.tools.gnu autotools helpers and the VirtualBuildEnv and VirtualRunEnv generator.

Creating environment files

EnvVars object can generate environment files (shell, bat or powershell scripts):

  1. def generate(self):
  2.     env1 = Environment()
  3.     env1.define("foo", "var")
  4.     envvars = env1.vars(self)
  5.     envvars.save_script("my_env_file")

Although it potentially could be used in other methods, this functionality is intended to work in the generate() method.

It will generate automatically a my_env_file.bat for Windows systems or my_env_file.sh otherwise.

In Windows, it is possible to opt-in to generate Powershell .ps1 scripts instead of .bat ones, using the conf tools.env.virtualenv:powershell=True.

Also, by default, Conan will automatically append that launcher file path to a list that will be used to create a conanbuild.bat|sh|ps1 file aggregating all the launchers in order. The conanbuild.sh|bat|ps1 launcher will be created after the execution of the generate() method.

The scope argument ("build" by default) can be used to define different scope of environment files, to aggregate them separately. For example, using a scope="run", like the VirtualRunEnv generator does, will aggregate and create a conanrun.bat|sh|ps1 script:

  1. def generate(self):
  2.     env1 = Environment()
  3.     env1.define("foo", "var")
  4.     envvars = env1.vars(self, scope="run")
  5.     # Will append "my_env_file" to "conanrun.bat|sh|ps1"
  6.     envvars.save_script("my_env_file")

You can also use scope=None argument to avoid appending the script to the aggregated conanbuild.bat|sh|ps1:

  1. env1 = Environment()
  2. env1.define("foo", "var")
  3. # Will not append "my_env_file" to "conanbuild.bat|sh|ps1"
  4. envvars = env1.vars(self, scope=None)
  5. envvars.save_script("my_env_file")

Running with environment files

The conanbuild.bat|sh|ps1 launcher will be executed by default before calling every self.run() command. This would be typically done in the build() method.

You can change the default launcher with the env argument of self.run():

  1. ...
  2. def build(self):
  3.     # This will automatically wrap the "foo" command with the correct environment:
  4.     # source my_env_file.sh && foo
  5.     # my_env_file.bat && foo
  6.     # powershell my_env_file.ps1 ; cmd c/ foo
  7.     self.run("foo", env=["my_env_file"])

Applying the environment variables

As an alternative to running a command, environments can be applied in the python environment:

  1. from conan.tools.env import Environment
  3. env1 = Environment()
  4. env1.define("foo", "var")
  5. envvars = env1.vars(self)
  6. with envvars.apply():
  7.    # Here os.getenv("foo") == "var"
  8.    ...

Iterating the variables

You can iterate the environment variables of an EnvVars object like this:

  1. env1 = Environment()
  2. env1.append("foo", "var")
  3. env1.append("foo", "var2")
  4. envvars = env1.vars(self)
  5. for name, value in envvars.items():
  6.     assert name == "foo":
  7.     assert value == "var var2"

The current value of the environment variable in the system is replaced in the returned value. This happens when variables are appended or prepended. If a placeholder is desired instead of the actual value, it is possible to use the variable_reference argument with a jinja template syntax, so a string with that resolved template will be returned instead:

  1. env1 = Environment()
  2. env1.append("foo", "var")
  3. envvars = env1.vars(self)
  4. for name, value in envvars.items(variable_reference="$penv{{{name}}}""):
  5.     assert name == "foo":
  6.     assert value == "$penv{{foo}} var"

Warning

In Windows, there is a limit to the size of environment variables, a total of 32K for the whole environment, but specifically the PATH variable has a limit of 2048 characters. That means that the above utils could hit that limit, for example for large dependency graphs where all packages contribute to the PATH env-var.

This can be mitigated by:

  • Putting the Conan cache closer to C:/ for shorter paths

  • Better definition of what dependencies can contribute to the PATH env-var

  • Other mechanisms for things like running with many shared libraries dependencies with too many .dlls, like deployers

Reference

class EnvVars(conanfile, values, scope)

Represents an instance of environment variables for a given system. It is obtained from the generic Environment class.

  • get(name, default=None, variable_reference=None)

    get the value of a env-var

    • Parameters:

      • name – The name of the environment variable.

      • default – The returned value if the variable doesn’t exist, by default None.

      • variable_reference – if specified, use a variable reference instead of the pre-existing value of environment variable, where {name} can be used to refer to the name of the variable.

  • items(variable_reference=None)

    returns {str: str} (varname: value)

    • Parameters:

      variable_reference – if specified, use a variable reference instead of the pre-existing value of environment variable, where {name} can be used to refer to the name of the variable.

  • apply()

    Context manager to apply the declared variables to the current os.environ restoring the original environment when the context ends.

  • save_script(filename)

    Saves a script file (bat, sh, ps1) with a launcher to set the environment. If the conf “tools.env.virtualenv:powershell” is set to True it will generate powershell launchers if Windows.

    • Parameters:

      filename – Name of the file to generate. If the extension is provided, it will generate the launcher script for that extension, otherwise the format will be deduced checking if we are running inside Windows (checking also the subsystem) or not.