[bug] 2.0 Woes

[shakfu]

Environment details

• Operating System+version: macOS, linux, windows 11
• Compiler+version: gcc 12+
• Conan version: 2.0.0
• Python version: 3.10.x

Steps to reproduce

My conanfile.txt:

[requires]
bdwgc/8.2.2
pcre/8.45

[generators]
cmake_find_package
cmake_paths

[options]
bdwgc:cplusplus=True
bdwgc:cord=False
bdwgc:gcj_support=False
bdwgc:java_finalization=False
bdwgc:shared=False
pcre:build_pcrecpp=True
pcre:build_pcregrep=False
pcre:shared=False
pcre:with_bzip2=False
pcre:with_zlib=False

% cd build
% conan install .. --build=missing

ERROR: The default build profile '/Users/sa/.conan2/profiles/default' doesn't exist.
You need to create a default profile (type 'conan profile detect' command)
or specify your own profile with '--profile:build=<myprofile>'

 % conan profile detect
Found apple-clang 14.0
apple-clang>=13, using the major as version
Detected profile:
[settings]
arch=x86_64
build_type=Release
compiler=apple-clang
compiler.cppstd=gnu17
compiler.libcxx=libc++
compiler.version=14
os=Macos

% conan install .. --build=missing

ERROR: Error while parsing [options] in conanfile
Options should be specified as 'pkg:option=value'

Clearly my options are well specified and working in conan 1.59.0 so why am I getting an error here?

Logs

No response

[memsharded]

Hi @shakfu

There are a few things that Conan 2.0 has change wrt Conan 1.X.
Please have a look to https://docs.conan.io/1/conan_v2.html

You need to do -o pkg*:option=value, all are patterns now, need "*"
Also cmake_find_package, cmake_paths have been removed, you need to use the new ones (already available in 1.X)

[shakfu]

Ok, but I'm not sure why it was decided that it was somehow ok for a package manager to break everyone's working conanfile.txt. I guess the lessons of the python2 to python3 transition were somehow forgotten.

[requires]
bdwgc/8.2.2
pcre/8.45

[generators]
CMakeDeps
CMakeToolchain

[options]
bdwgc/*:cplusplus=True
bdwgc/*:cord=False
bdwgc/*:gcj_support=False
bdwgc/*:java_finalization=False
bdwgc/*:shared=False
pcre/*:build_pcrecpp=True
pcre/*:build_pcregrep=False
pcre/*:shared=False
pcre/*:with_bzip2=False
pcre/*:with_zlib=False

[memsharded]

Ok, but I'm not sure why it was decided that it was somehow ok for a package manager to break everyone's working conanfile.txt. I guess the lessons of the python2 to python3 transition were somehow forgotten.

We have been supporting python2-3 compatibility for years to forget about this.
This is why the syntax about the CMakeDeps and CMakeToolchain and the patterns pkg/** for options have been available for very long time in Conan 1.X.

We have also done, regarding the major (major means breaking by the semver standard) Conan 2.0 release to help everyone to be ready for it:

• 6 alpha releases
• 10 beta releases (alphas and betas, like 1 per month, that means, this has been running for more than 1 year and a half)
• Sharing in social every one of these releases
• 4 conference talks about the upcoming Conan 2.0
• Shared the releases in the release mailing list anyone can subscribe
• Announcing it in our blog posts
• Writing a dedicated, first level section in the docs about what is necessary to migrate to 2.0
• We are building hundreds of recipes of ConanCenter with both 1.X and 2.0, so it cannot be say that they are very incompatible versions.

[shakfu]

We have been supporting python2-3 compatibility for years to forget about this.
This is why the syntax about the CMakeDeps and CMakeToolchain and the patterns pkg/** for options have been available for very long time in Conan 1.X.

...

We are building hundreds of recipes of ConanCenter with both 1.X and 2.0, so it cannot be say that they are very incompatible versions.

I'm sure you have all gone out of your way and put in major efforts to introduce the new features in 2.0, but I respectfully and strongly disagree with the decision to break compatibility with 1.0 conanfile.txt syntax.

Any 1.0 conanfile.txt syntax should be 100% compatible with conan 2.0 and if someone wants to use the pattern matching syntax then they can, but everything keeps working if they don't. This is a minimum expectation from a package management system.

Can you imagine if any other package manager (like pip or cargo, broke compatibility with prior requirements.txt or Cargo.toml syntax on a major version change?

[memsharded]

Well, we agree to disagree :)

Feature deprecations and removal is completely standard in SW development. Even the extremely backward compatible C++ standard deprecates and removes things from it. So code that was valid (but deprecated) and compiled in the previous version is absolutely broken in the new C++ version because it was removed from the standard.
You can check https://en.cppreference.com/w/cpp/17 to see how C++17 removed auto_ptr, random_shuffle, trigraphs and others.

Regarding what you said about other package managers, please have a look to https://pip.pypa.io/en/stable/news/ pip changelog, there are tons of deprecations and removals. I think some of them affected client side files like the removal of the git@git... syntax, the removal of setuptools_scm>=3.5[toml] syntax, etc. from requirements.txt files. They do this in major releases of pip of course, but major releases of pip have indeed removed things that worked in the past in requirements.txt files.

Rust cargo is still in 1.X, didn't do a major release yet, so we cannot know.

Php composer also did some removals in their 2.0, like not allowing some package names: https://github.com/composer/composer/blob/main/UPGRADE-2.0.md

Any 1.0 conanfile.txt syntax should be 100% compatible with conan 2.0 and if someone wants to use the pattern matching syntax then they can, but everything keeps working if they don't. This is a minimum expectation from a package management system.

We have completely removed generators like cmake, cmake_find_package in 2.0, and features like imports. There is no way these features are moving into 2.0, they have been deprecated already in 1.X and replaced with better alternatives. Getting rid of those things is the only possibility to keep maintenance and development of Conan possible.

In any case, thanks very much for your feedback, and I am sorry for the inconvenience.
If the syntax to upgrade is clear, and we will not declare this as a bug, could we close this ticket?

[shakfu]

Fair enough if we have a difference of opinion.

Honestly, I can't get the 2.0 version of the conanfile above working for some reason. So I'm currently specifying in our requirements.txt for 'conan==1.59.0' which has been working great so far.

[memsharded]

Ok, sounds good to pin 1.59 at the moment, we will keep supporting it for some time. But please note that eventually the community of contributors to ConanCenter will start pushing for using 2.0 features in ConanCenter, and 1.X support for packages there will have to be sunset. It is likely that even after that 1.X will keep being supported for a while for users that have their own copy of the packages (or just they private packages) in previous versions, but at some point it will be necessary to upgrade.

I suggest to close this issue as regarding the conanfile.txt syntax, and if you want to report new issues in the 2.0 upgrade, you can file new specific tickets with more information. I suspect it could be related to the transparent CMake integration, that now doesn't need any modification to users CMakeLists.txt (a massive request by Conan users), and is driven by find_package() and -DCMAKE_TOOLCHAIN_FILE=.../conan_toolchain.cmake.

[oxygene]

Any specific reason why my_lib:my_option=True is not just treated as shortcut to my_lib/*:my_option=True? I find the latter to be quite counterintuitive and unnecessarily complex to write. It makes the learning curve steep and gives me a hard time explaining to my colleagues why adopting Conan is a good idea despite it being so pedantic at certain situations ;)

[memsharded]

Yes, there is a reason for this, we are not unnecessarily pedantic, but we really tried to solve some issues regarding ambiguous inputs:

If we use the rule above, I guess that you also mean that my_lib/1.3:myoption=True should be equivalent to my_lib/1.3*:myoption=True or my_lib/1.3@*:myoption=True? And if you do my_lib/1.3@user:myoption=True, it should be equivalent to my_lib/1.3@user/*:myoption=True?

In both cases, that approach would be broken, because it doesn't allow to differentiate between packages with and without user/channel. This also goes for only the channel part, because Conan 2.0 allows to specify only the user and not the channel. This is a situation that has happened a bunch of times, kind of common situation for many users that have zlib/1.2.11 from ConanCenter and also zlib/1.2.11@mycompany/stable, and they couldn't distinguish them in command line or in profiles.

The new syntax make it very explicit:

• conan create . -o zlib/1.2.11:shared=True will make the pkg zlib/1.2.11 shared library
• conan create . -o zlib/1.2.11:shared=True --user=myteam will make the pkg zlib/1.2.11@myteam not shared (default is False)
• conan create . -o zlib/1.2.11*:shared=True will make it a shared library for all user/channel that could be defined

This same problem is repeated in many other places (--build=mylib/*, per-package settings, etc)

[michael-brade]

It also works to use boost/shared=True, so no version or wildcard necessary. However, I have a problem with the error message when the syntax is not correct - it says:

ERROR: Error while parsing [options] in conanfile
Options should be specified as 'pkg:option=value'

And clearly, that is wrong and leads to a waste of time when searching for the reason why the apparently correct syntax doesn't work anymore. Please fix the text 😁

[oxygene]

Thanks for taking the time to elaborate.

If we use the rule above, I guess that you also mean that my_lib/1.3:myoption=True should be equivalent to my_lib/1.3*:myoption=True or my_lib/1.3@*:myoption=True? And if you do my_lib/1.3@user:myoption=True, it should be equivalent to my_lib/1.3@user/*:myoption=True?

Well, I see where this is leading to. While the package name and version follow a hierarchical concept (which fits well with a shorthand notation), this breaks down when introducing the concept of user and even more with a vague channel, especially with those being optional. Got it.

But I think we could improve the error message a little bit. Right now for the option boost:bzip2=False we get the following message:

Error while initializing options. The usage of package names boost:bzip2 in options is deprecated, use a pattern like boost/* or boost* instead

It mentions the full option key in the first part of the sentence, but the proposal only contains the package name portion of it. What about adding the option to make the full syntax more clear?

Error while initializing options. The usage of package names boost:bzip2 in options is deprecated, use a pattern like boost/*:bzip2 instead

You see that I also left out the second example of using boost* as a pattern. Unless I miss something again, this seems error-prone. Wouldn't using boost* also match some library with the name booster that could appear in future? The same is the case for the documentation at https://docs.conan.io/1/migrating_to_2.0/commands.html#unified-patterns-in-command-arguments. It proposes to use zlib* instead of zlib/* again leaving room for ambiguities. What are your thoughts on this?

[memsharded]

And clearly, that is wrong and leads to a waste of time when searching for the reason why the apparently correct syntax doesn't work anymore. Please fix the text

@michael-brade Yes, you are right, lets fix that error message.

[memsharded]

To complement #13266 and conan-io/docs#3032, also fixed the 2.0 docs (only 1 occurrence) in conan-io/docs@a4b3fef

[memsharded]

I think after the above PRs have been merged and the discussion above on why being explicit about when it is a pattern and when not is necessary to disambiguate some broken cases in 1.X, we can close this issue.

Thanks all for the feedback and the contributions!