0

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?

1 Answers1

1

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.

uilianries
  • 3,363
  • 15
  • 28
  • I can see why you would think that i want to affect requirements - this is not the case. That i put it in the `requirements`-method was just because i was certain that this method would be called on install. I like both ways that you posted, but there is a big caveat: In my case the provider doesn't know the key of the environment-variable that the consumer must set. As far as i can tell both of your solutions assume a knowledge about the key. Well, but if `Any` is to be understood as in "any python-object", i guess i can build something from your first way, providing key-value pairs... – LeonTheProfessional Jul 17 '20 at 19:37
  • If there would be a way that does not need modifications to the provider i would still be very happy to hear it though! – LeonTheProfessional Jul 17 '20 at 19:47
  • okay, i cannot use options, as they are considered to require changes to the binary, and i am packaging an existing binary not to be rebuilt on install.. – LeonTheProfessional Jul 17 '20 at 20:07
  • 1
    You can remove any option from package id, so it's not a problem: https://docs.conan.io/en/latest/creating_packages/define_abi_compatibility.html#defining-a-custom-package-id I gonna update my original answer – uilianries Jul 17 '20 at 20:28
  • If someone stumbles upon this, here is the issue for the [feature-request](https://github.com/conan-io/conan/issues/7381) i have made to conan.io. Depending upon when you read this thread, there might be a more natural solution to this.. – LeonTheProfessional Jul 18 '20 at 07:47