[question] Alternative to conandata.yml

Our internal package repository is structured in a similar way to CCI. Thus we also place a conandata.yml file next to conanfile.py where we specify download urls and hashes for the sources of the package.

While this works great, it has one big drawback: when adding a new version of a library, the package gets a new revision (because the conandata.yml calculates into the package hash), and all previously build packages versions will be rebuild, though effectively nothing has changed for them.

Has anyone experimented with any alternative approaches to tackle this problem?

E.g. basically two things come to my mind: move the information from conandata.yml to config.yml (up one folder) which effectively is NOT part of the recipe, and have the conanfile.py be a template, into which that information is injected prior to conan exporting it. Or, somehow injecting it to the conan export command, the same way, --version 1.x.y is already injected to the recipe.

The latter approach definately needs some Conan feature to realize it, on the first one, you probably need some python / scripting logic to get from a template to an actual conanfile.py.

A jinja template for a conanfile like that could basically be like:

class CMakeConan(ConanFile):
    name = "cmake"
    version = {{ version }}
    settings = "os"

    def sources(self):
            download_info["url"] = {{ url }}
            download_info["sha256"] = {{ sha256 }}
            tools.get(**download_info)

Thus without a conandata.yml file, but the following config.yml

versions:
  "3.14.0":
    folder: all
    url: https://path/to/source-3.14.0.zip
    sha: a42503efae....
  "3.15.5":
    folder: all
    url: https://path/to/source-3.15.5.zip
    sha: 29371eaf49...

Does anybody take a similar approach? Any thoughts?

[KerstinKeller]

Works like a charm! Thanks again.

[memsharded]

Any way to roll out the hook to everybody, except manually via conan config set or globally via distributing a common conan.conf?

Yes, conan config install works incrementally for conan.conf. So having the hook in the repo, plus a conan.conf that contains only the [hooks] section with your hook name to activate it, would apply it without touching the cache path that can be different for everybody.