There is no “compatible with 2.X” commands introduced in Conan 1.X. You will need to adapt to the new commands once you migrate to Conan 2.0.

For a comparison of some 1.x versus 2.0 commands, see the Conan 2.0 Cheat Sheet Blog Post.

Changes to expect

JSON output in 2.X commands

In Conan version 1.X, you can use the --json flag followed by the path to the output file when executing commands. For example:

conan create ... --json=path/to/file.json

Starting with Conan version 2.0, you are expected to use the --format flag followed by the output format type, and redirect standard output to a file. The same command in version 2.0 would be:

conan create ... --format=json > path/to/file.json

For more information, please check the Conan 2 commands reference

conan install

Almost the same command, the major change is the way to specify (or complete if not defined) the fields of the reference. Remember that in Conan 1.X you have to specify the build profile or activate the conf core:default_build_profile=default.

$ conan install . [--name=mylib] [--version=1.0] [-pr:b=build_profile] [-pr:h=host_profile]

In addition the --install-folder has been replaced with --output-folder. You might need to provide both arguments in Conan 1.X as some legacy generated files (conaninfo.txt, conanbuildinfo.txt, etc) are not affected by --output-folder.

conan build

In addition the --build-folder has been replaced with --output-folder. Still in most cases you shouldn’t be using it, but relying on the defined layout() in the recipe.

conan create

Same changes as conan install:

$ conan create . [--name=mylib] [--version=1.0] [-pr:b=build_profile] [-pr:h=host_profile]

conan graph info

This is the substitute of the old “conan info”. The syntax is very similar to conan install and conan create

$ conan graph info . [--name=mylib] [--version=1.0] [-pr:b=build_profile] [-pr:h=host_profile]

conan remote login

This is the substitute of the old “conan user”.

$ conan remote login [-h] [-f FORMAT] [-v [V]] [--logger] [-p [PASSWORD]] remote username

conan upload

The default behavior has changed from requiring –all to include the binary packages to –recipe-only for just the recipe

$ conan upload [-h] [-v [V]] [--logger] [-p PACKAGE_QUERY] -r REMOTE
               [--only-recipe] [--force] [--check] [-c]

Unified patterns in command arguments

The arguments in Conan 1.X where we specified recipe names require now a valid reference pattern. A valid reference pattern contains the * character or at least the name/version part of a reference (name/version@user/channel).

There are some examples:

  • The --build argument when referring to a package:

 conan install . --build zlib
 conan install . --build zlib/*
 conan install . --build zlib/1.2.11
 conan install . --build zlib/1.*
  • The --options and --settings arguments when used scoped:

 conan install . -s zlib:arch=x86 -o zlib:shared=True
 conan install . -s zlib/*:arch=x86 -o zlib/*:shared=True
 conan install . -s zlib/1.2.11@user/channel:arch=x86 -o zlib/1.2.11:shared=True

Commands which have been removed

Removed “conan package”

The conan package command has been removed. If you are developing a recipe and want to test that the package method is correct, we recommend using the conan export-pkg . instead and exploring the package folder in the cache to check if everything is ok.

Removed “conan copy”

Do not use the conan copy command to change user/channel. Packages will be immutable, and this command will disappear in 2.0. Package promotions are generally done on the server-side, copying packages from one server repository to another repository.

Removed “conan user”

This has been replaced with the remote login command in 2.0.

Removed “conan config set”

We are no longer implementing file-editing commands in 2.0. A bit overkill conan config set to edit one file. Which should very rarely happen, the file is updated with conan config install. Alternatively, you can use the command line and profiles to pass these values.

Removed “conan alias”

The conan alias command has been removed in Conan 2.0. The use of aliases is no longer recommended due to significant improvements in version handling and version ranges that surpass the capabilities of Conan 1.X.

Although the command has been removed and the feature will be completely removed in future versions, it is still possible to create aliases in Conan 2.0 for compatibility purposes. This is achieved using the alias template in Conan 2.0 and exporting the recipe:

$ conan new alias -d name=mypkg -d version=latest -d target=1.0
$ conan export .

Note that when requiring the alias, you must place the version in parentheses () to explicitly declare the use of an alias as a requirement:

class Consumer(ConanFile):

    requires = "mypkg/(latest)"

For users still relying on alias, it is recommended to consider migrating to the newer versioning mechanisms introduced in Conan 2.0, such as the dynamic selection of pre-releases for easier testing. This change aligns with general trends in package management and version control, where explicit aliases are not commonly used in other package managers. Please, check the versioning section in the Conan 2.0 docs.

Custom commands

You can build custom commands on top of the Conan Python API. Refer to the Conan 2.0 documentation for custom commands.