Add non-settings properties to packages from the conanfile.py

We have found that we wish for a property like system for our conan packages at times. These properties could be used to convey information about what exact code was used to build the package, configure options and other information that is useful when debugging issues in production, example of these properties could be:

• Link to SCM (link to github page with the commit directly)
• Slave used to build the package
• Exact configure options used to build this package
• Link to CI with the log of this current build

While some of the above could be solved with artifactory properties I think that there could be some really nice benefit of being able to set these properties dynamically and could give better visibility into what exact software is being used.

This requires the properties to be searchable or at least viewable with conan info/search as well.

[memsharded]

The only way would be to capture some state of the original repo, and “export” it as well, similar to conaninfo.txt, but for the initial export. That file can be loaded by the recipe when it is loaded.

[Aalmann]

This information should be part of the conaninfo.txt or conanmanifest.txt

I think one of the Conan base requirements should be / is, that one can always restore the sources used to built the binary package. Btw. there should also be a minimum Conan version information in the conaninfo to make sure that the used python code is running (the code self.env_info.path.append(os.path.join(self.package_folder, "bin")) only works with Conan 0.26.x but not with 0.25.x and lower)

IMHO there should be a user scm_details(given in the recipe, probably with or without revision) to be able clone/checkout the sources when the recipe lives in another repo. Then source() is called and because of the given user scm_details Conan does a checkout/clone etc. If the recipe lives in the same repo the scm class should handle that (e.g. by ignoring because it is already checked out or by checkout which may lead to the problem that the recipe could change in that moment). When creating the package, Conan should retrieve the “real” scm-details (revision, branch, url and either a possible diff file if there are local modifications or Conan should stop processing). These information will be written into the manifest or conaninfo file. With that information Conan will always be able to restore the exact sources which were used to build the package (assumed that there is an SCM set and used and that there is no source tarball). If the package is then used by another user, it will be downloaded into the local cache (and not in user space). When (re)build of the package is required, Conan would check the conanfile and probably override the scm_details which are given in the manifest or info.

So I suggest to add the optional scm_details-attribute to ConanFile which has some restrictions, but when using it in the right way, Conan will always make sure, that the sources matches.