memsharded
commented
1 year ago Hi @SpaceIm
When we changed this for Conan 2.0 is because we had consistent feedback that the default of overriding without even noticing was not a good one, and more and more users were using CONAN_ERROR_ON_OVERRIDE.
Having a conf that changes back this behavior might not be a good approach for ConanCenter:
- If ConanCenter activates the conf, to keep moving without conflicts, then users, that will not have this configuration defined by default, will get the conflicts themselves. That is, the CI of ConanCenter will not detect the issues, that will hit directly the users.
- We cannot force the users to define the configuration. We can document it, for sure, but they will get to it only when they experience the above confusing conflicts, and they will struggle a lot until they find the solution, as it is not evident that possible configuration as solution.
- We cannot change the built-in behavior, that would be equivalent to returning to 1.X behavior, and this is undesired
So the way to move forward, both for ConanCenter and for enterprise users with their own recipes is similar:
- It is necessary to solve conflicts explicitly. Having a
force=Trueoroverride=Trueallows for easy identification in recipes, grepping, etc, where there are recipes that are resolving conflicts. - For recipes that happen at the moment of closing the diamond downstream, it is easy. The developer writing the recipe will resolve the conflict.
- For conflicts that happen due to new versions being
requiredby some consumers but no others, the way to move forward is to detect those conflicts as soon as possible and converge as soon as possible to the latest (or the stable) versions. ConanCenter might implement these checks too, running nightly or something. To be discussed. - It is possible that using version ranges would also simplify some things. This is standard practice in practically all package managers, and it was not feasible in the past with Conan, because of some limitations (speed of the server to respond for queries necessary to resolve ranges), that have already been solved. Having recipes in ConanCenter to have
self.requires("openssl/[>=1.1 <2.0])might make a lot of sense. To be discussed too.
It is important to recall that the current state of ConanCenter is often problematic. I have talked to a bunch of enterprise users that have forks of conan-center-index and basically the major divergence from upstream is making all versions converge to avoid the conflicts that otherwise regularly happen when using multiple dependencies (companies using 50-80 recipes from ConanCenter is not unusual). It is important that we start to proactively address this with infrastructural solutions
SpaceIm
db4
What is your suggestion?
In conan v2, versions conflicts are not resolved automatically. Even a direct dependency of top conanfile does not override transitive dependency version if force=True is not explicitly set in conanfile.py (and it's impossible in conanfile.txt or command line). While this behavior might be desirable in companies with well written conanfile.py, lockfile etc, I don't think it's appropriate for new comers or simple projects with a conanfile.txt, or while testing a recipe with
conan create, because versions conflicts will always happen in sufficiently complex dependency graphs. conan-center has never been able to provide a global dependency graph without versions conflicts between transitive dependencies during the past 3 years (just a new version of zlib or openssl takes months to be propagated to all conan-center recipes), so how could it scale?Therefore I think a config changing the behavior as if all direct dependencies had
force=True(recursively) would be convenient.I'm pretty sure that conan-center will be beaten by this graph model very quickly in recipes with many direct & transitive dependencies, like arrow, cairo, cpython, drogon, ffmpeg, folly, gdal, grpc, itk, opencv, qt etc.
Have you read the CONTRIBUTING guide?