[question] Should dependencies with visible=False be visible in downstream lockfiles?

[DoDoENT]

What is your question?

I'm creating a package that contains only an executable. Since it's a binary, I don't want it rebuilt every time downstream overrides some of its dependencies.

Therefore, I required the dependencies with package_id_mode='unrelated_mode' and visible=False.

However, when I then run conan lock create --tool-requires mypackage/<version>, the generated lockfile still contains all dependencies.

Is that supposed to happen or should the lockfile contain only mypackage/<version>#hash, without its dependencies, as they should not be visible?

I'm using conan 2.0.13.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[schwaerz]

I have the same - or similar question:
We also build an application. We see the same thing: Dependencies will be visible in the consumer package where the application is used as a build requirement.

Looks like cannot even be fixed by using test=True or visible=False, build=True (the latter one with explicitly generating the cmake packages via deps.build_context_activated = [<dep1>, <dep2>, ...]) I was wondering whether there should be either

• An explicit option to mark a dependency as completely hidden
• Or static libraries should always be hidden when building an application?

[memsharded]

Sorry this was not responded back then.

Yes, the visible trait is not related to the graph expansion, it is only related to C++ artifacts (headers/libs) or executables (runtime exes, dlls) visibility. It might affect if the binaries are actually retrieved or not, but the full graph of recipes is always fully computed.

This was proposed and approved in conan-io/tribe#20. Retrieving just a conanfile.py is very fast, and having the graph fully computed always have tons of advantages, solving a lot of problems in 1.X, and with very reduced extra cost.

[schwaerz]

Thanks for the update.

I was merely asking as we deploy our Conan-built binaries (exe, dll, so, ...: Applications) as Conan packages. Those binaries will be re-used as tool dependency in other Conan projects.

Unfortunately the conan.lock files of those projects will even contain the packages references which have been fully consumed (i.e. static library dependencies).

If I want to get rid of those entries in conan.lock, will I have to re-package those binary packages?

[memsharded]

Unfortunately the conan.lock files of those projects will even contain the packages references which have been fully consumed (i.e. static library dependencies).

Yes, the key reason why these are necessary in the lockfile is that even static library dependencies versions and revisions are critical to compute the package_id of their consumers, specially when they are shared libraries or executables. If you don't have the exact version and revision of a static library, even if you don't need its binary, then it is physically impossible to compute the package_id of the consumers, and then it is not possible to resolve the graph and install the binaries that are needed. Dropping those static libraries from the lockfile, which is possible with conan lock remove, might pull a newest version or revision and then result in a "missing binary" of the consumer shared-library, because indeed it would need to rebuild a new binary if the dependency is a new one.

So the only mechanism in which full isolation is possible would be to re-package the shared-libraries. This is not possible at the moment in Conan as built-in (it is relatively doable with some juggling, like install+deploy+export-pkg or the like), and we will be trying to implement it as built-in in #13171 if you want to track it.

[schwaerz]

Thanks :)
Tracking now #13171

[memsharded]

The "vendor" feature has been merged for next Conan 2.4 in #16073, I am closing this ticket as solved by it (visible=False is about visibility, not full vendoring and isolation, but the new feature will provide full isolation), if there are any questions, please create a new ticket, thanks!