[question] is there a way to access dependency options from the requirements function ?

[mohamed-omara39]

What is your question?

I am currently testing with conan and I want to be able to control the visible of a dependency of mine based on an one of its options . is there a way to access dependency options from the requirements function ?

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @mohamed-omara39

The requirements() method is evaluated to compute what will be the dependencies. But the dependencies are not there yet, they are typically in the server side, they haven't been even downloaded. So it is physically impossible to request the options values of that dependency, because it doesn't exist yet.

So this would be some "chicken and egg problem", cannot be done.

Depending on the problem you are trying to solve (please elaborate if you'd like more feedback, provide the problem description), there could be other approaches, like using a user conf, using the new vendor=True feature, etc.

[mohamed-omara39]

This is a dummy example of my usecase currently simplemath has two versions 1.0.0 and 2.0.0 and I want to limit the visible trait of the simplemath/1.0.0 to disallow the version conflict to happen through the options of advancedMath/1.0.0 .but as you stated it is a egg and chicken scenario

[memsharded]

And visibility cannot simply be restricted by visible=False trait, that is just a declaration for Conan that some special logic is already implemented in the packages. The packages source code themselves need to fully isolate things:

• Make sure no public headers are included in public headers
• Make sure there is no API or ABI leakage over the interfaces
• Make sure the build model is a fully embedded one, like a shared library linking a static library.

If all of the above is true, you can make advanced_math/1.0 to have a requires("simple_math/1.0", visible=False).
But if not, visible=False will just make the builds break.

[mohamed-omara39]

is there a conan api though that can be used to fetch the options of a package . as I would like to implement a custom command to retrive the options of an dependency of a reciepe

[memsharded]

There is no such thing as the "options of a dependency of a recipe".
You can have a recipe, like myapp/1.0 that contains a requires("mylib/1.0").

You can easily have 2, or even more, different builds of myapp/1.0, that will result in different package_id for myapp/1.0:

• conan create . -o *:shared=False -s build_type=Release
• conan create . -o *:shared=True -s build_type=Release (all deps shared)
• conan create . -o mylib/*:shared=True -s build_type=Release (only mylib shared, others dep static)
• conan create . -o *:shared=False -s build_type=Debug
• conan create . -o *:shared=True -s build_type=Debug (all deps shared)
• conan create . -o mylib/*:shared=True -s build_type=Debug (only mylib shared, others dep static)
• etc

So for exactly the same recipe of myapp/1.0, with exactly the same requires("mylib/1.0") you will get multiple different dependency graphs, with different options and configurations, resulting in different binaries for myapp/1.0. In many of those cases, other options in recipes like fPIC might be even exist or not depending on the OS too (fPIC does not exist in Windows, for example), so you would need to factor above every other settings, including OS, compiler, architecture...

In all those cases you can just do --format=json > graph.json and you will get a thorough dump of the dependency graph, including the exact options of each package.

But I think you are not considering options as their main intent: to be an imperative input to the system. You as user defines the values to build one thing or the other. It is not generally a good practice to try to check dependencies options to do anything, it is the other way round, options mandate what should be done.

Could you also please clarify if your advanced_math package above does fullfill all the necessary requirements to define requires("math/1.0", visible=False)? Like:

• It is a shared library
• its dependency math/1.0 is a static library
• no public header of advanced_math contains any header of math
• There is not other API or ABI leakage accross the advanced_math API, like advanced_math reading or returning any objects from the math library

Because otherwise, the above would be just a plain library conflict, and the code needs to evolve to be able to depend on the same version of math.