Closed Adnn closed 1 month ago
Hi @Adnn
yes, this is expected and by design.
We found that the use case of having the same dependency both as requires
and tool_requires
is relatively common, and as it is not possible to disambiguate the 2 different dependencies in a single self.dependencies["mydep"]
, there was the option of raising an error like KeyError
-like about having 2 different dependencies with the same name.
But then, it is also possible to inject [tool_requires]
from profiles, that could mean in some occassions that a code that was valid in a recipe for self.dependencies["mydep"]
was suddenly crashing due to the injected requirement. But it was "evident" from the point of view of the recipe writer that such expression should always refer to the "host" dependency and not the build one.
Furthermore, the use case for accessing directly tool-requires
dependencies from the self.dependencies
interface was very low compared to the one of accessing host dependencies.
So we decided to use that behavior, the self.dependencies[]
operator works exclusively for host
dependencies, not build
, and if users want to directly access build dependencies self.dependencies.build[]
is necessary. I understand it might be surprising in some cases, but we have found that it works pretty nicely for the majority of cases.
Thank you @memsharded for this detailed explanation, this clears things up!
Great! Happy to help. Closing this ticket as resolved, thanks for your feedback.
What is your question?
We found a behaviour that surprised us (Conan 2.5.0 on Windows):
self.dependencies
, when iterated viaitems()
orvalues()
, contains all dependencies (which is consistent with the documentation).Yet, when indexing via
operator[]
and the upstream name (suchself.dependencies["upstream"]
), the host requirements are found, but not the tool (build) requirements. Tool requirements can only be indexed onself.dependencies.build
.Is it an expected behaviour?