What’s new in Conan 2

Conan 2 comes with many exciting improvements based on the lessons learned in the last years with Conan 1.X. Also, a lot of effort has been made to backport necessary things to Conan 1.X to make the upgrade easier: Recipes using latest 1.X integrations will be compatible with Conan 2, and binaries for both versions will not collide and be able to live in the same server repositories.

Conan 2 migration guide

If you are using Conan 1.X, please read the Conan 2 Migration guide , to start preparing your package recipes to 2.0 and be aware of some changes while you still work in Conan 1.X. That guide summarizes the above mentioned backports to make the upgrade easier.

New graph model

Conan 2 defines new requirement traits (headers, libs, build, run, test, package_id_mode, options, transitive_headers, transitive_libs) and package types (static, shared, application, header-only) to better represent the relations that happen with C and C++ binaries, like executables or shared libraries linking static libraries or shared libraries.

Read more:

New public Python API

A new modular Python API is made available, public and documented. This is a real API, with building blocks that are already used to build the Conan built-in commands, but that will allow further extensions. There are subapis for different functional groups, like api.list, api.search, api.remove, api.profile, api.graph, api.upload, api.remotes, etc. that will allow to implement advanced user flows, functionality and automation.

Read more:

New build system integrations

Introduced in latest Conan 1.X, Conan 2 will use modern build system integrations like CMakeDeps and CMakeToolchain that are fully transparent CMake integration (i.e. the consuming CMakeLists.txt doesn’t need to be aware at all about Conan). These integrations can also achieve a better IDE integration, for example via CMakePresets.json.

Read more:

New custom user commands

Conan 2 allows extending Conan with custom user commands, written in python that can be called as conan xxxx. These commands can be shared and installed with conan config install, and have layers of commands and subcommands. The custom user commands use the new 2.0 public Python API to implement their functionality.

New CLI

Conan 2 has redesigned the CLI for better consistency, removing ambiguities, and improving the user experience. The new CLI also sends all the information, warning, and error messages to stderr, while keeping the final result in stdout, allowing multiple output formats like --format=html or --format=json and using redirects to create files --format=json > myfile.json. The information provided by the CLI will be more structured and thorough so that it can be used more easily for automation, especially in CI/CD systems.

Read more:

New deployers

Conan 2 implements “deployers”, which can be called in the command line as conan install …. --deployer=mydeploy, typically to perform copy operations from the Conan cache to user folders. Such deployers can be built-in (“full_deploy” and “direct_deploy” are provided so far), or user-defined, which can be shared and managed with conan config install. Deployers run before generators, and they can change the target folders. For example, if the --deployer=full_deploy deployer runs before CMakeDeps, the files generated by CMakeDeps will point to the local copy in the user folder done by the full_deploy deployer, and not to the Conan cache.

Deployers can be multi-configuration. Running conan install . --deployer=full_deploy repeatedly for different profiles, can achieve a fully self-contained project, including all the artifacts, binaries, and build files that is completely independent of Conan and no longer require Conan at all to build.

New package_id

Conan 2 defines a new, dynamic package_id that is a great improvement over the limitations of Conan 1.X. This package_id will take into account the package types and types of requirements to implement a more meaningful strategy, depending on the scenario. For example, it is well known that when an application myapp is linking a static library mylib, any change in the binary of the static library mylib requires re-building the application myapp. So Conan will default to a mode like full_mode that will generate a new myapp package_id, for every change in the mylib recipe or binary. While a dependency between a static library mylib_a that is used by``mylib_b`` in general does not imply that a change in mylib_b always needs a rebuild of mylib_a, and that relationship can default to a minor_mode mode. In Conan 2, the one doing modifications to mylib_a can better express whether the consumer mylib_b needs to rebuild or not, based on the version bump (patch version bump will not trigger a rebuild while a minor version bump will trigger it)

Furthermore the default versioning scheme in Conan has been generalized to any number of digits and letters, as opposed to the official “semver” that uses just 3 fields.

compatibility.py

Conan 2 features a new extension mechanism to define binary compatibility at a global level. A compatibility.py file in the Conan cache will be used to define which fallbacks of binaries should be used in case there is some missing binary for a given package. Conan will provide a default one to account for cppstd compatibility, and executables compatibility, but this extension is fully configurable by the user (and can also be shared and managed with conan config install)

New lockfiles

Lockfiles in Conan 2 have been greatly simplified and made way more flexible. Lockfiles are now modeled as lists of sorted references, which allow one single lockfile being used for multiple configurations, merging lockfiles, applying partially defined lockfiles, being strict or non-strict, adding user defined constraints to lockfiles, and much more.

Read more:

New configuration and environment management

The new configuration system called [conf] in profiles and command line, and introduced experimentally in Conan 1.X, is now the major mechanism to configure and control Conan behavior. The idea is that the configuration system is used to transmit information from Conan (a Conan profile) to Conan (A Conan recipe, or a Conan build system integration like CMakeToolchain). This new configuration system can define strings, boolean, lists, being cleaner, more structured and powerful than using environment variables. A better, more explicit environment management, also introduced in Conan 1.X is now the way to pass information from Conan (profiles) to tools (like compilers, build systems).

Read more:

Multi-revision cache

The Conan cache has been completely redesigned to allow storing more than one revision at a time. It has also shortened the paths, using hashes, removing the need to use short_paths in Windows. Note that the cache is still not concurrent, so parallel jobs or tasks should use independent caches.

New extensions plugins

Several extension points, named “plugins” have been added, to provide advanced and typically orthogonal functionality to what the Conan recipes implement. These plugins can be shared, managed and installed via conan config install

Profile checker

A new profile.py extension point is provided that can be used to perform operations on the profile after it has been processed. A default implementation that checks that the given compiler version is capable of supporting the given compiler cppstd is provided, but this is fully customizable by the user.

Command wrapper

A new cmd_wrapper.py extension provides a way to wrap any conanfile.py command (i.e., anything that runs inside self.run() in a recipe), in a new command. This functionality can be useful for wrapping build commands in build optimization tools as IncrediBuild or compile caches.

Package signing

A new sign.py extension has been added to implement signing and verifying of packages. As the awareness about the importance of software supply chain security grows, it is becoming more important the capability of being able to sign and verify software packages. This extension point will soon get a plugin implementation based on Sigstore.

Package immutability optimizations

The thorough use of revisions (already introduced in Conan 1.X as opt-in in https://docs.conan.io/en/latest/versioning/revisions.html) in Conan 2, together with the declaration of artifacts immutability allows for improved processes, downloading, installing and updated dependencies as well as uploading dependencies.

The revisions allow accurate traceability of artifacts, and thus allows better update flows. For example, it will be easier to get different binaries for different configurations from different repositories, as long as they were created from the same recipe revision.

The package transfers, uploads, downloads, will also be more efficient, based on revisions. As long as a given revision exists on the server or in the cache, Conan will not transfer artifacts at all for that package.