[bug] Cannot override version of build requirement

[Sil3ntStorm]

Environment Details (include every applicable attribute)

• Operating System+version: Any
• Compiler+version: Any
• Conan version: 1.49.0
• Python version: 3.9.7

Steps to reproduce (Include if Applicable)

from conans import ConanFile, tools
from conans.errors import ConanInvalidConfiguration

class BugDemoConan(ConanFile):
    name = 'bug_demo_project'
    version = '0.3.0'
    author = 'Nobody <nobody@cares.invalid>'
    url = 'www.bugz.com'
    description = 'Bug Demo'
    license = 'Unlicense'
    settings = 'os', 'compiler', 'build_type', 'arch'
    generators = 'cmake'
    build_requires = (
        'nlohmann_json/3.10.5',
        'ms-gsl/4.0.0',
        'spdlog/1.10.0',
        'fmt/8.0.1', # Override dependency version of spdlog
    )

Logs (Executed commands with output) (Include/Attach if Applicable)

conan create .
Exporting package recipe
bug_demo_project/0.2.6: A new conanfile.py version was exported
bug_demo_project/0.2.6: Folder: <snip>.conan\data\bug_demo_project\0.2.6\_\_\export
bug_demo_project/0.2.6: Exported revision: a13b2144d454a418de826090b45a5592
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.version=17
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

bug_demo_project/0.2.6: Forced build from source
ERROR: Conflict in bug_demo_project/0.2.6:
    'bug_demo_project/0.2.6' requires 'fmt/8.0.1' while 'spdlog/1.10.0' requires 'fmt/8.1.1'.
    To fix this conflict you need to override the package 'fmt' in your root package.

[memsharded]

Yes, build_requires cannot be overriden because they are designed to be "private" to the package that uses them. They can only be redefined in the [build_requires] section of the profile

A couple of important things:

• Don't use regular libraries as build_requires. Conan docs already advice that as a bad practice (https://docs.conan.io/en/latest/devtools/build_requires.html#tool-requirements). Those should be regular requires and build_requires is intended for build tools.
• You need to start using --profile:build=xxxx --profile:host=yyyy for graphs containing build_requires, because that is the mode that will be used in 2.0 always. And it changes how the graph is evaluated, build_requires will be put in the "build" context with the "profile:build" settings. And they will not conflict. Still, their versions cannot be overriden in 1.X, but they will not conflict with "host" requirements

[Sil3ntStorm]

Which then leads to the question of how you can have a recipe that requires libraries for building it, but that are private to this recipe and consumers of said recipe do not have those requirements. Unless of course they want to use them, at which point they need to require them on its own.

If I am building a library that requires header only libraries for example then the consumers of said recipe don't need to have those.

[memsharded]

Those issues have been addressed for Conan 2.0:

• https://www.youtube.com/watch?v=kKGglzm5ous
• New requirements traits tribe#26
• New package_type to complete model information tribe#27

[Sil3ntStorm]

The currently desired use case was talked about in the video you linked. Have a recipe that requires stuff, builds a fully linked native thing and thus any consumer does not have any of the dependencies of said recipe.
It appears that will only be possible with conan 2.0 if I understood correctly.

[memsharded]

It is possible in Conan 1.X under some situations. For example, linkers are typically smart enough to discard unused things, so propagating a static library down to the consumer via shared intermediate one, might be fully discarded, no effect. If that is not the case, it is also possible to use some build system-fu, like CMake stripping unwanted libraries, but yes, I know that can be tricky.

[Sil3ntStorm]

Well in this case it's more a thing of the stuff still being downloaded and (potentially) built (despite being completely unnecessary), which the goal was to avoid that

[Sil3ntStorm]

So just to clarify:
Conan 1.x would never consider a binary created by conan 2.x as a valid binary, as the package id generation was changed.
So even if it works with conan 2.x generating a binary, then nobody using 1.x would find said binary package, and everyone using 1.x would end up trying to build a 2.x package (and presumably fail miserably).
Even if every consumer would run 2.x, it wouldn't be possible to have dependencies as those on CCI are mostly still 1.x recipes (for a valid reason) and 2.x would fail to parse / build those.

So it appears to me that the following are the only options right now:

• Convert all required dependencies to 2.x and fork them (not really an option), then require consumers to use 2.x as well.
• Wait for 6+ months for 2.x to be released (ie. stable) and the dependencies from CCI to be converted to 2.x
• Hack the final cmake file in order to remove the linkage and includes. It would still attempt to download the files and require to have a successful build of them in order for conan install to succeed.

[memsharded]

So even if it works with conan 2.x generating a binary, then nobody using 1.x would find said binary package, and everyone using 1.x would end up trying to build a 2.x package (and presumably fail miserably).
Even if every consumer would run 2.x, it wouldn't be possible to have dependencies as those on CCI are mostly still 1.x recipes (for a valid reason) and 2.x would fail to parse / build those.

I think it is important to highlight that the recipes themselves can be fully compatible both in Conan 1.X and Conan 2.0. We will do the same for ConanCenter, recipes will build simultaneously binaries for 1.X and 2.0. Users using 1.X will still get their binaries for 1.X and users using 2.0 will get the binaries built with 2.0. With exactly the same common recipe.

[memsharded]

Closing this as solved in 2.0 (to be released very soon)