Conan does not evaluate evaluate compatibility of version requirements by design

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
  • conan

    Conan - The open-source C and C++ package manager

  • This is a surprising feature of the Conan C++ package manager: It allows to specify dependencies of packages, and also to specify ranges of dependencies, but it does not a way to automatically resolve them. The responsibility for the resolution is with the resulting application at the top of the graph, it has to provide version numbers or ranges for all conflicting dependencies, regardless how deep thy are in the dependency graph.

    Here some more information:

    https://docs.conan.io/en/1.22/versioning/version_ranges.html...

    See also:

    https://github.com/conan-io/conan/issues/9547

    I think dependency resolution in systems of networked software is a tough problem, and I believe there is only one solution that will scale well enough: Requiring strict backward compatibility on every level.

    If you think that there is another way, consider this:

    Application A requires dependencies D1.0 and E1.0. Both D and E require a library L1.0 , this we have a "diamond dependency structure". And as it is C++, let's assume that L is either dynamically linked, or has versioning requirements that are visible outside, for example data formats.

    Now, L1.0 makes a breaking change, and, not following semantic versioning, labels the new version as L1.1. This could be a library like boost, which is used by many thousands of applications.

    Now, let's assume that D1.0 has an urgent security vulnerability (may be it is related to logging ?) and ships a new emergency release D1.1, which happens to use L1.1. And let's assume that D is well tested with that. But the incompatible change in L1.1 happens to break E. And this means that application A cannot be upgraded.

    The corollary is that if your library D includes another library L as a dependency which introduces a breaking change, and that library is visible to the outside (that is, not statically linked and only internally used), then the breaking change in L causes a breaking change in your library D. This means that being backwards incompatible is a transitive property - you only achieve backwards incompatibility in a system if every relevant part of it is backward compatible.

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

    WorkOS logo
NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts