[package] bzip2/1.0.8: setting pkg_config names fails in Conan 1.19.4

datalogics-kam commented 4 years ago

Package and Environment Details (include every applicable attribute)

Package Name/Version: bzip2/1.0.8
Operating System+version: any
Compiler+version: any
Docker image: n/a
Conan version: conan 1.19.4
Python version: Python 3.6.8

Conan profile (output of `conan profile show default` or `conan profile show <profile>` if custom profile is in use)

[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=apple-clang
compiler.libcxx=libc++
compiler.version=10.0
os=Macos
os.version=10.9
os_build=Macos
[options]
[build_requires]
*: cmake_installer/[~=3.15]@conan/stable
[env]
DEVELOPER_DIR=/Applications/Xcode-10.3.app/Contents/Developer
MACOSX_DEPLOYMENT_TARGET=10.9

Steps to reproduce (Include if Applicable)

conan install bzip2/1.0.8@

Any profile will do; this is a recipe failure.

Logs (Include/Attach if Applicable)

Click to expand log

``` Configuration: [settings] arch=x86_64 arch_build=x86_64 build_type=Release compiler=apple-clang compiler.libcxx=libc++ compiler.version=9.1 os=Macos os_build=Macos [options] [build_requires] [env] Installing package: bzip2/1.0.8 Requirements bzip2/1.0.8 from 'conan-center-virtual' - Cache Packages bzip2/1.0.8:3c88ad122762d62115d2625c9e8e54c12417952a - Download bzip2/1.0.8: Retrieving package 3c88ad122762d62115d2625c9e8e54c12417952a from remote 'conan-center-virtual' Downloading conanmanifest.txt: 100%|##########| 251/251 [00:00<00:00, 339kB/s] Downloading conaninfo.txt: 100%|##########| 464/464 [00:00<00:00, 981kB/s] Downloading conan_package.tgz: 100%|##########| 88.7k/88.7k [00:00<00:00, 47.3MB/s] Decompressing conan_package.tgz: 100%|##########| 88.7k/88.7k [00:00<00:00, 14.1MB/s] bzip2/1.0.8: Package installed 3c88ad122762d62115d2625c9e8e54c12417952a bzip2/1.0.8: Downloaded package revision e4cc3886a58b639c0ee7a7895134ccb3 ERROR: bzip2/1.0.8: Error in package_info() method, line 57 self.cpp_info.names["pkg_config"] = "bzip2" TypeError: '_CppInfo' object does not support item assignment ```

datalogics-kam commented 4 years ago

I'm told this needs Conan 1.21.

We have some code that uses the Conan API that require us to do some testing before changing Conan versions, so we don't do it that often. We do upgrade bugfix releases.

I'm going to try to pin a recipe revision in our project, but I'm having a hard time figuring that out at the moment. I know there is a previous recipe, and I can see it in our Artifactory cache, but I can't seem to make Conan use it.

How do I make it use this:

I've tried:

bzip2/1.0.8@_/_#9f45d38c70cd945d7032b3da668a199b
bzip2/1.0.8@#9f45d38c70cd945d7032b3da668a199b

datalogics-kam commented 4 years ago

Oh, the answer is some of them are in Bintray, and some aren't. I should be looking in the local conan-center-remote-cache.

datalogics-kam commented 4 years ago

I was able to pin to bzip2/1.0.8#0c6c48836d6d52d8b384195c7d1aed6a, so at least we're back in production. This was a surprise to us, incidentally.

uilianries commented 4 years ago

I'm told this needs Conan 1.21.

It's true, Since Conan 1.21 you can use custom names for generators: https://docs.conan.io/en/latest/reference/conanfile/attributes.html#cpp-info https://docs.conan.io/en/latest/changelog.html#dec-2019

I was able to pin to bzip2/1.0.8#0c6c48836d6d52d8b384195c7d1aed6a, so at least we're back in production. This was a surprise to us, incidentally.

Revisions is the best way if you want to keep using 1.19, but as you should know, we strongly recommend update you Conan client. This new features improves a lot the cases when a generator has a specific name which does not match to the package name. Also, there is note about latest Conan version is a requirement in the Wiki: https://github.com/conan-io/conan-center-index/wiki#before-start

datalogics-kam commented 4 years ago

We do some complex work (including using Conan Package Tools) via the API, and the API is not guaranteed to be constant across minor changes, so we depend on it with conan~=1.19.0. When I change that, I have to test some things. This takes a little time, and most of the fixes have been easy. But I have to combine it with my other responsibilities.

I can appreciate that Conan is improving, and the conan-center-index makes it easier to track all the recipes. It also means that the recipes change quickly.

Some kind of version compatiblity window would be great, like maybe if the repo had the Conan version as a property, and the search could find a compatible RREV.

Or I may have to do some pinning...it'd be really great if we could pin RREVs of a certain remote only, so our local stuff could float, and then we could plan points where we do deliberate upgrades, perhaps near the beginning of a release cycle.

uilianries commented 4 years ago

I see your point of view, @danimtb @jgsogo do you have some idea about creating compatibility window for recipes?

danimtb commented 4 years ago

I think to provide such a window is something unmaintainable since this repo if community driven and we declare it works with the latest Conan version. We cannot test all recipes with different versions of Conan and waiting to introduce new features in recipes will be against the development of Conan itself.

@datalogics-kam I strongly recommend you to upload your 3rd party recipes in an Artifactory and do not sync them continuously to the latest changes of this repo, as that would mean "living on the edge". I'd recommend you to only sync with conan-center recipes whenever you upgrade the Conan version and try the recipes with small examples before.

Hope that makes sense

datalogics-kam commented 4 years ago

I strongly recommend you to upload your 3rd party recipes in an Artifactory

@danimtb That's a pretty good idea. Doing it that way would be a lot of manual extra work, but the same thing can be accomplished with the RREV.

If I built the product once, then the working recipe is already cached in our Artifactory (and presumably still exists in Bintray as well).

What I need is a lock for the RREV. conan.lock is too comprehensive of a lock; it's got resolved packages and settings and options, and PREVs and the profile.

What I'm considering is to write a bit of code for our internal tools:

Scan the dependency graph, including transitive dependencies
Only consider dependencies from non-local remotes (ours all end in -virtual), or defined usernames (say, bincrafters, conan, and _)
write a dependency with RREV (for example bzip2/1.0.8#0c6c48836d6d52d8b384195c7d1aed6a) to a list in the recipes_lock key in the conandata.yml
Our conanfile.py can then read that list and add them with self.requires(). This is only a few lines of code.
It's easy enough to take entries out of the conandata.yml to repin them.

I think that'll make our builds resistant to upstream recipe changes. Some kind of lightweight recipe-only pinning might be useful in the base Conan product.

Thoughts?

conan-io / conan-center-index