[question] What is the difference between test_requires() or build_requires(, force_host_context=True) and requires with "private" flag?

[SzBosch]

What is your question?

What is the difference between test_requires() or build_requires(, force_host_context=True) and requires with "private" flag?

This refers to the documentation:
https://docs.conan.io/1/devtools/build_requires.html#build-and-host-contexts
https://docs.conan.io/1/reference/conanfile/attributes.html#requires

e.g. what is the difference between:

def build_requirements(self):
        self.test_requires("pkgA/0.1")

and

def requirements(self):
        self.requires("pkgA/0.1", "private")

?

I assume in both cases it does not lead to transitive dependencies and they are in the host context, right?

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @SzBosch

Thanks for your queston.

Yes, both cases they are not transitive and they are in the host context.
There is one important difference is that requires() in Conan 1 are evaluated always, while build_requires are only evaluated if the package has to be built from sources. This might create an unwanted dependency to the testing framework that is not really necessary.

Another important difference is that test_requires() keeps working in Conan 2.0, even with [test_requires] syntax for conanfile.txt, while the private qualifier has been removed, so it will break.

[SzBosch]

Thank You for the answer.

One detail is unclear to me: When a require is private what is the use-case/advantage of being "always evaluated"?

[memsharded]

Not really a use-case or advantage, but it could be confusing for 1.X users: "why I have gtest in my dependencies graph, if I am not building from source anything". Conan 1.X users that run promotion to server "production-release" repositories, where they only promote (copy) the final target packages in "release" mode, they would have their builds failing, because gtest was not promoted to the production-release repository, yet a dependency in the graph.

Conan 2.0 changes these rules, and the graph is always complete, containing all dependencies (recipes, not necessarily binaries)

[MTomBosch]

That means: When looking at the GTest example in the last comment and using Conan 2. at least the GTest recipe would need to be promoted alaways to the releases repository whereas in Conan 1.x with Gtest as build requires it is not required. Is my understanding correct?

[memsharded]

Yes, the full graph of recipes need to be promoted. The binaries are not necessary, but the recipes are needed, as the full graph will always be computed when using conan install commands. Other ways to download packages, like conan download will not require the recipes.

[SzBosch]

I guess this is true also for transitive tool dependencies. Means when a package A has tool_requires and test_requires which itself have requires, which for each can have further requires, tool_requires and test_requires and I want to promote the package A, I need to expose my whole toolchain (recipes) to my users/customers (which use "conan install pkgA").

This sounds for me like drawback with Conan 2 compared to Conan 1.

[memsharded]

I need to expose my whole toolchain (recipes) to my users/customers (which use "conan install pkgA").

Yes, it is true, the recipes need to be available to resolve a dependency graph.

This sounds for me like drawback with Conan 2 compared to Conan 1.

You can find the rationale, design, problems that it is solving and the discussion with the Tribe in conan-io/tribe#20, and see the comments and the voting there too.

The amount of problems and issues of not computing the complete graph in Conan 1.X was huge. One of the top causes of issues and problems, user confusions, etc.

The trade-off was making some recipes visible to external customers (only the recipes), which in practice didn't seem a blocker for the vast majority of users. If hiding a few python files to those customers is completely mandatory, then releasing to them the exact same dependency graph used for internal development is probably not the best approach. For achieving almost absolute isolation of the upstream dependencies for secondary release flows (like releasing packages to an external customer, outside of the main development flow), the "repackage" concept will try to be implemented in the 2.X roadmap, this is the ticket that you might want to follow: #13171