new core.sources.patch:extra_path conf

[memsharded]

Docs for conan-io/conan#17520

[MartinDelille]

This documentation doesn't help so much to understand how to apply a patch from a consumer recipe.

How can I set core.sources.patch:extra_path ?

[memsharded]

It can't. All core.xxxx configurations can only be applied from global.conf or a --core-conf command line argument.

[MartinDelille]

You mean that I can not have two projects on my system: one using minizip from CCI and another one using a patched version ?

[memsharded]

You mean that I can not have two projects on my system: one using minizip from CCI and another one using a patched version ?

You can have 2 different revisions from minizip, one coming directly from ConanCenter, and the other a local one you built applying your own patches. These two revisions can co-exist in the cache, as any other revisions, and you can use them in different projects, by using a lockfile to guarantee that you are using the specific revision that you want.

What is not possible is to apply patches to upstream dependencies from a recipe. They must be applied at conan create time of the dependency (in this case minizip), injecting patches via the global.conf or command line arg --core-conf.

[MartinDelille]

How can I use the patched minizip in my project then ?

[memsharded]

How can I use the patched minizip in my project then ?

I am not sure what you mean. You create the patched minizip package binary, and use it as any other package. The consumer recipe has to do nothing, the management of the patched package belongs to the package, and it is done at conan create time of that package.

This is a feature for package creation. If you are using modified (or patched) packages from ConanCenter see https://docs.conan.io/2/devops/using_conancenter.html

[MartinDelille]

I’m not sure it will be very easy to use for what I am trying to achieve. After doing some contribution to the godot engine, I wanted to see if it would be possible to move to conan for dependency management.
I tried to switch to conan only for minizip to study the possibility and found that there is the following patch: https://github.com/godotengine/godot/blob/master/thirdparty/minizip/patches/godot-seek.patch
I’m not sure if I could find an easy way to handle this patch.

[memsharded]

I understand now what you are trying to achieve.

This will not be possible with the core.sources.patch:extra_path_conf, it is not the intended use case.

For some cases I'd say try to contribute the patch to ConanCenter, if the patch is relevant and interesting enough for the larger audience. But I have seen https://github.com/godotengine/godot/blob/master/thirdparty/minizip/patches/godot-seek.patch, and there is no way this can be merged into ConanCenter, it is too specific.

So it depends a bit on what the focus would be, there are 2 scenarios:

• We want godot to be a Conan package itself, and be easily usable via ConanCenter, for example.
• We only want to improve the dependency management of Godot, without making a Conan package out of Godot itself.

In both cases, leaving minizip vendored in godot by now, is not a bad thing per se. If we are not making a Conan package, then no problem at all, unless there are other dependencies that transitively depend on minizip. If we were going to make a Conan package, it will only be an issue for downstream consumers that might also have a Conan requires("minizip..."). But when that happens, that will be a good problem to have, worse than that is not having the Godot package at all for anyone.

For the case of just wanting to solve the dependency management for Godot, it might be possible to use a fork of ConanCenter via the local-recipes-index feature: https://docs.conan.io/2/devops/devops_local_recipes_index.html. With this feature, the ConanCenter conan-center-index fork can apply any patches, and the conan install for godot can resolve dependencies against this fork directly, instead of resolving against ConanCenter.