Closed wuziq closed 1 week ago
Hi @wuziq thanks for the question. You're mostly on point with your discoveries, and it does boil down to the trimming of the conandata.yml
file!
We don't have this hook installed, so why are we seeing this behavior while building boost?
As I see, you're using the local recipes index remote type, and one of its goals is to match the behaviour of Conan Center Index, where we do trim the conandata for each version, so that recipes fetched from this remote type algo get trimmed. You're not seeing this behaviour when compiling it because the trim happens internally within the local remote.
For you to get the same behaviour of locally created packages, you do need to have a post_export()
hook that calls [conan.tools.files.conandata.trim_conandata()](https://docs.conan.io/2/reference/tools/files/basic.html#conan.tools.files.conandata.trim_conandata)
.
This file needs to go into your <conan2_home>/extenions/hooks/
folder (docs for naming conventions etc here), something like:
_~/.conan2/extensions/hooks/hook_trimconandata.py
from conan.tools.files.conandata import trim_conandata
def post_export(conanfile):
trim_conandata(conanfile)
The way to share/install this across your developers would be using the conan config install
command and associated features, docs here
Let me know if this helps :)
Fascinating, thank you! This leads me to another question. When building our own private conan center index, should we not be calling conan create
as I showed above? Should we be building the recipes differently? We don't mind using the hook, but we're curious whether we can avoid adding the hook.
We are following this: https://docs.conan.io/2/devops/conancenter/hosting_binaries.html It says to create a list of the packages we want, and to then call conan create --build=missing
.
However, I just noticed in another document (https://docs.conan.io/2/devops/devops_local_recipes_index.html#building-binaries-from-a-private-conan-center-index-fork), it says to use conan install --requires=...
.
Which is correct?
Maybe we are not calling conan create
correctly?
Extra note about my prior message:
Note that trim_conandata()
raises if any of your packages does not have a conandata.yml
file. If this is undesired, pass False
as the second parameter which will disable the behaviour and silently do nothing
When building our own private conan center index, should we not be calling conan create as I showed above?
You are calling conan create
mostly correctly :) I'll explain the differences between the install and create below, but for now:
conan create ./conan-center-index/recipes/zlib/all --build=missing --name zlib --version 1.3.1 -pr:a=default -r local-index
instead of adding the path to the end of the command. This can save you from some hard to debug issues later on if we happen to change some syntax in the argument parser--name=zlib
, it is included in every CCI recipe by default=
to separate argument names from values (so --version=1.3.1
instead of --version 1.3.1
), it will save you some possible issues too :)The docs mention conan install
because the idea there is that you're not creating the packages, but using them as part of the dependencies for a project you're running, but which you're not creating the package at that moment. Your conan create
call is best suited for your case, as you want to create the zlib
package and be able to later upload it to a remote/use it from your cache, which is different than having the recipe be available from a local recipes index :)
Thank you!
What is your question?
TLDR: The conandata.yml changes depending on whether the recipe is built directly vs built via
--build=missing
. Why?Details:
We are building zlib/1.3.1:
conan create --build=missing --name zlib --version 1.3.1 -pr:a=default -r local-index ./conan-center-index/recipes/zlib/all
This yields:
However, when we build another package that depends on zlib, the recipe revision is different. For example, with boost:
conan create --build=missing --name boost --version 1.71.0 -pr:a=default -r local-index ./conan-center-index/recipes/boost/all
This yields:
Comparing the recipe revisions
e20
andf52
, the only difference is in the conandata.yml file. When we build zlib directly, the conandata.yml matches exactly what is contained in the conan-center-index. However, when zlib is built via the boost build, zlib's conandata.yml is much smaller, containing only the source and patch paths for version 1.3.1.I found this thread: https://github.com/conan-io/conan/issues/13874 It mentions
hook_reduce_conandata.yml
from https://github.com/conan-io/hooks.Questions:
We don't have this hook installed, so why are we seeing this behavior while building boost?
Maybe it happens automatically for packages that are built because of
--build=missing
? If so, we should install this hook so that we get the same behavior when building packages directly, correct?If so, what's the correct way to install this hook in Conan2? (the hooks readme is geared towards Conan1 - there is no
conan config set
in Conan2).Have you read the CONTRIBUTING guide?