[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?

• [X] 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 https://github.com/conan-io/tribe/pull/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: https://github.com/conan-io/conan/issues/13171

[memsharded]

To follow up on this:

• Making dependencies optional is still totally possible in Conan 2, and it can be done easily for test_requires for example, if we know what we want to do and want to avoid the propagation is as simple as:

  def build_requirements(self):
  if self.conf.get("tools.build:skip_test", check_type=bool):
      self.test_requires("catch2/...")
      self.test_requires("other/...")

  And then you can fully drop the dependencies and they will not even exist in your lockfile, promotions or graphs. The same concept can be applied to your tool_requires if you want, by using a user-conf.

The "vendor" feature has been merged in https://github.com/conan-io/conan/issues/13171 for next Conan 2.4. This feature can also provide a complete dependency graph isolation in cases it could make sense. It doesn't look like this would be exactly about this thread, but just in case.

I am closing this ticket as responded, but please re-open or create a new one if there is any further question or comment. Thanks!

[memsharded]

Actually, I think at the light of the vendor feature that something more could be done to improve this. I am re-opening and assigning to 2.5 for research it