[question] Dependency graph with components

[docbrown1955]

What is your question?

I have a question regarding components and indirect dependencies. Say I have a lib package with a small and large library (respectively lib::small and lib::large components).

The lib::large component is actually depending on boost to provide higher-level utilities than the lib::small component that does not depend on anything.

Now, consumers of my lib package might only want to consume lib::small and not care about lib::large. If I understand correctly, by defining the component requirements in the package_info() method the large component will not be linked if using CMake for example, and that's good.

However, I'm also interested in letting consumers of my package free of downloading boost if they do not use lib::large. As far as I understand this is not possible and boost is always in the dependency graph of the consumer packages. Below is the ideal dependency graph for the situation with an exe consuming only lib::small.

graph TD
    exe --> lib::small
    lib::large --> lib::small
    lib::large --> boost
    subgraph LibPackage
       lib::small
       lib::large 
    end
    subgraph ExePackage
       exe
    end

To be more precise on what I would expect, here is what I tried:

# Recipe for lib, with a 'small' and 'large' components
def package_info(self):
    self.cpp_info.components["small"].libs = ["small_lib"]
    self.cpp_info.components["large"].libs = ["large_lib"]
    self.cpp_info.components["small"].requires = []
    self.cpp_info.components["large"].requires = ["small", "boost::boost"]

# Recipe for exe, trying to depend only on the small component and not depend on boost
def package_info(self):
    self.cpp_info.requires = ["lib::small"]

I'm aware that in all cases the 'lib' package must be fetched as a whole including the lib::large component library, I would simply like indirect dependencies to be removed from the graph if no dependency to lib::large is declared in the consumer recipe (and if a dependency to lib::small is explicitly declared).

The use case is mainly, in a large code base, to avoid having too many packages and still allowing the dependency graph to be reasonable with this additional granularity provided by conan's components.

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[memsharded]

Hi @docbrown1955

Thanks for your question. I think you mostly realized about the behavior. The summary would be:

• Conan packages dependency graph do not take into account components at all. It expands based on requires
• The decision of which packages can be skip and not downloaded is based purely on the package_id of the package, the package_type and the requirements traits. No components are involved in this process either.
• The package_info() method of every recipe, can only be executed when the package as been already downloaded, and is existing in disk. This is due some use cases like collect_libs() tool, or anything that needs the artifacts to be in disk to define the package information or cpp_info.
• As the package_info() executes after the package has been downloaded, it is impossible to use the components defined in it to do any kind of decision of what packages to download or not
• The components are then just a "linking" mechanism. They avoid to link too many unused libraries from dependencies, with faster linking and avoiding the risk of linking too many unused binary code.

[docbrown1955]

Hi @memsharded,

Thanks a lot for the clarification!

It would have been very nice but I understand that it does not really fit in the way conan manages components and requirements.

[memsharded]

Yeah, as components consumption can really change from the consumer side, in different projects or even in the same project over time, having some influence over the package compilation and distribution would imply infinite variability and extremely complex management of the binaries.

If this is clarified, maybe we can close this issue as responded?