[Feature request / UX] Improve override=True ergonomics: warn on no-op overrides, and consider a more explicit trait name

[NokiDev]

What is your suggestion?

When override=True is added to an existing direct self.requires(...), the requirement silently stops being a dependency of the package (it disappears from self.dependencies, no CMakeDeps config with include dirs is generated, etc.). This is the documented behavior, and force is the correct tool when the package is directly consumed — I understand the force vs override distinction.

The problem is purely ergonomic, and there are two complementary improvements:

1. Warn on no-op / misused overrides (primary proposal)

Emit a warning at graph-resolution time when a require with override=True does not actually override any transitive node. This almost always means the author meant force=True. Today it fails silently: no warning, the package drops out of the graph, and the build breaks later, far from the cause.

2. Consider a more explicit trait name (secondary, non-breaking)

The name override reads as "override the version of this dependency," whereas it actually means "this is not a dependency, only a transitive version constraint." The trait that distinguishes the two behaviors is really whether the dependency edge is kept:

force=True → keeps the edge, wins version conflicts.
override=True → no edge, version constraint only.
Without breaking existing recipes, a more self-documenting alias (e.g. override_transitive=True) for the current override behavior would make intent obvious at the call site and reduce the recurring force vs override confusion. override could stay as a kept alias.

Example:

# pkgB/conanfile.py — consumes headers from foo
def requirements(self):
    self.requires("foo/1.0")                  # direct; foo headers used in pkgB code

# changing it to:
    self.requires("foo/1.0", override=True)   # foo silently drops out of the graph,
                                              # no warning; build later fails on missing foo headers

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @NokiDev

Thanks for the feedback.

Emit a warning at graph-resolution time when a require with override=True does not actually override any transitive node. This almost always means the author meant force=True. Today it fails silently: no warning, the package drops out of the graph, and the build breaks later, far from the cause.

The problem with this is that very often there are conditional requirements depending on the platform and other conditions.
Replicating all those conditions on the consumer side can be very challenging, so doing nothing when the dependency doesn't exist is a feature in this regard. If now we add a warning when the override is not used, it can make the builds of users that define warnings_as_errors with what could be reported as false positives.

Consider a more explicit trait name (secondary, non-breaking)
The name override reads as "override the version of this dependency," whereas it actually means "this is not a dependency, only a transitive version constraint." The trait that distinguishes the two behaviors is really whether the dependency edge is kept:

Overrides are already documented as temporary solutions, workarounds, and discouraged for most cases. Adding more traits that make it more complex, will add extra maintenance, future support, documentation, etc. For something that shouldn't be ergonomic in the first place, because overrides are a problematic thing and only there for temporary workarounds.

So considering the risks and the cost/value ratio, at the moment it doesn't seem something that would be planned as a new feature. The recommendation is less overrides, no more. Many thanks for the feedback anyway!