CODEWITHSUNDEEP
conan
LeonTheProfessional
LeonTheProfessional

Reputation: 374

Add to conan virtualenv from consumer

This is about the virtualenv-generator of conan:

I have a provider-package that defines environment-variables using self.env_info. This means that when doing conan install in my consumer-package, i receive a convenient activate.sh script that sets up my virtual environment.

However i would like to add some environment-variables to this virtual environment from my consumer. Of course i could just add these manually, or write a simple wrapper-script that uses the environment-variables from my provider and adds a few itself. This means creating custom solutions though, and i would like to only use conan for these things wherever possible.

Basically, i want my consumer-provided environment-variables to land inside environment.sh.env as soon as i execute conan install. An acceptable alternative would be if they landed there when i execute conan build

One thing i've tried:

def requirements(self):
    self.env_info.FOO = "bar"

But, as described in the docs self.env_info is only defined inside the package_infomethod.

Is there the possibility within conan of extending the environment-variables of a provider-package from a consumer-package?

Upvotes: 0

Views: 1743

Answers (1)

uilianries
uilianries

Reputation: 3887

You can use a special option which can support anything: ANY

https://docs.conan.io/en/latest/reference/conanfile/attributes.html#options

class FooConan(ConanFile):

    options = {"custom_env": "ANY"}
    default_options = {"custom_env": tools.get_env("MYENVVAR")}

    def package_id(self):
        del self.info.options.FOO # Doesn't affect the package ID

    def package_info(self):
        self.env_info.FOO = self.options.custom_env

The example above shows a recipe which receive a custom option, and it doesn't affect id, and is used for customer environment.

Anyway, self.env_info in not supposed to be used when installing, it's consumed when building a package. The virtualrunenv is able to change your PATH, which can useful if you need to run a specific tool which is packaged.

A second way, and more dynamic, as cpp_info is dynamic, you can consume directly from user environment:

class FooConan(ConanFile):
    ...
    def package_info(self):
        self.env_info.FOO = tools.get_env("FOO", "waka waka")

In this case, when running conan install <ref> -g virtualenv, the environment.sh.env will contain FOO=waka waka OR, if FOO is declared in consumer environment, the FOO's value from consumer env.

If you want to affect your requirements, using env vars, do not do it! Requirements affects the package ID, Conan options is the best solution.

Upvotes: 1

Related Questions