conan info reverse(Consumer list)

[chreniuc]

To help us debug your issue please explain:

• [x] I've read the CONTRIBUTING guide.
• [x] I've specified the Conan version, operating system version and any tool that can be relevant.
• [x] I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

Conan version: 1.15.1

conan info is a very powerful command, it helps a lot. For example, getting the dependency list of a package: conan info math/1.0.1@user/stable -g index.html. Wonderful!

But we were wondering if we can the same thing in reverse, get all packages that use this package. For example I want to get a list of all packages that use the package math/1.0.1@user/stable, or the package that has the name math. Is this possible? I looked through the documentation and through the issues but I couldn't find anything.

Use case:

Every time we are updating a package, we would like to update all packages that use that package(to use the latest version of its dependencies). We know we can use override in the consumer app, but there can be problems with override.

For example this is a dependency graph:

executable -> custom_lib/1.0.0
executable -> custom_websocket/1.0.0
custom_lib/1.0.0 -> boost/1.68.0
custom_websocket/1.0.0 -> boost/1.68.0

Forcing from the conanfile of executable to use latest boost boost/1.70.0 by using override, may result in an error at link time(if those two packages: custom_lib and custom_websocket are already built with boost/1.68.0 in the local cache), because the boost asio api has changed from 1.68.0 to 1.70.0. Using --build=missing won't fix this issue, because the requirements do not get included in the package_id(so they won't get rebuilt). Using --build would fix this, but it is not ok to rebuid all dependencies every time(this is opposite to conans purpose, which is something like this: build once, use forever).

So this feature would be very useful for this purpose. I updated a package, now I want to update all packages that use that package.

Thanks.

[memsharded]

While we understand this would be a nice to have feature, there are a few things that make it really, really challenging:

• The dependency graph is conditional to the configuration, and it builds the dependency graph upwards. It is not possible to compute the dependency graph downwards without a combinatoric explosion (need to check all possible configurations of settings, options, etc).
• It would require parsing the entire repository conanfiles, or maintaining a DB. The former is impossible to do in the server, no way recipes are going to be evaluated there. And makes no sense in the client, because it would need to download the whole server repos. Maintaining a DB would be a really huge, huge effort, and a future maintenance burden we cannot afford.

For the problem you are describing, we are introducing lockfiles, you will be able to represent and store a snapshot of a full dependency graph, to achieve consistent builds and propagate downstream changes, making sure that the non affected parts of the graph doesn't change during the build. Follow progress here: https://github.com/conan-io/conan/pull/5035

[chreniuc]

@memsharded

Regarding your first point,

It is not possible to compute the dependency graph downwards without a combinatoric explosion (need to check all possible configurations of settings, options, etc).

For the dependency graph, yeah... But I do not see why we would need it here, but maybe I'm mistaking, you know better the insides of conan and how it would work for this feature.

Let's say the command will be called something like this: conan consumer.

When I call it like this: conan consumer math/1.0.1@user/stable -g index.html, it will give me a graph(list) of packages that use this package(math/1.0.1@user/stable) with the default options.

I can call it like this: conan consumer math/1.0.1@user/stable -o math:option=value -g index.html to force a specific option.

I can also force it to look for consumers in a specific remote: conan consumer math/1.0.1@user/stable -r remote -g index.html.

Regarding your second point, I agree. It would need to parse all conan files to see if the specific package is used in each package. The DB method would be a headache.

I will also take a look at lockfiles and try to see if we can use it.

Thanks for taking the time.

[memsharded]

Hi @chreniuc

When I call it like this: conan consumer math/1.0.1@user/stable -g index.html, it will give me a graph(list) of packages that use this package(math/1.0.1@user/stable) with the default options.

How? :)

How it knows who depends on it? Because the math/1.0.1 recipe does not contain any declaration of its consumer. Then one of either is necessary:

• Parse and evaluate all the recipes existing in the repository
• Maintain a DB of these consumer relations

The first is undoable, for security reasons, in the server (plus it will be ridiculously slow, for any non trivial repository. Many thousands of recipes are typical in a Conan repo). The second is an humongous effort, with high complexity and tons of future maintenance and support.

[chreniuc]

@memsharded

Regarding this:

How it knows who depends on it? Because the math/1.0.1 recipe does not contain any declaration of its consumer. Then one of either is necessary:

I did say how:

Regarding your second point, I agree. It would need to parse all conan files to see if the specific package is used in each package. The DB method would be a headache.

I understand that at this moment this is undoable, I didn't thought about it very long... Hopefully someone will come with a solution for this feature in the near future...

Thanks for taking the time. You can close this issue, I got everything I wanted to know :smiley:

[Radrik5]

Forcing from the conanfile of executable to use latest boost boost/1.70.0 by using override, may result in an error at link time(if those two packages: custom_lib and custom_websocket are already built with boost/1.68.0 in the local cache), because the boost asio api has changed from 1.68.0 to 1.70.0. Using --build=missing won't fix this issue, because the requirements do not get included in the package_id(so they won't get rebuilt). Using --build would fix this, but it is not ok to rebuid all dependencies every time(this is opposite to conans purpose, which is something like this: build once, use forever).

You can force custom_lib and custom_websocket to be rebuilt when boost version changes if you include minor version of boost into the package_id. For example, by using self.info.requires["boost"].minor_mode() in package_id() method in both custom_lib and custom_websocket packages.

Details: https://docs.conan.io/en/latest/creating_packages/define_abi_compatibility.html#define-abi-compatibility

[memsharded]

Thanks for the contribution @Radrik5

Indeed, using the package_id() can define what is needed to be built or not. Still not enough to know the dependants. But the lockfiles will be able to use this logic in package_id(), and that will be a complete solution to re-building downstream packages that should be re-built according to the defined rules when some package changes upstream.

Thanks @chreniuc for all the feedback! Sorry I skipped that paragraph, you are right, you said it. Agree, as this is not doable right now, closing it at the moment. Cheers!

[chreniuc]

@Radrik5

Thank you very much!!!! I didn't knew about this. This does solve our problem.