-
Notifications
You must be signed in to change notification settings - Fork 980
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New local-recipes-index
feature
#13930
New local-recipes-index
feature
#13930
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now running conan list "*:*" -r=local
for the current head of cci fails because it finds Conan 1-only recipes and does not get past that. A try-catch in the select()
method inner loop of subapi/list.py
might be enough to skip those cases?
I have improved that by running a quick check of |
To recap, some alternatives that might be nice to look into:
I think the UX feels better this way, and less confusion about protocols |
This is supercool, my only comments are about changing the UX a bit, I would vote for adding an argument or not adding anything and distinguish between them with the |
Lets add a explicit argument, just in case in the future we want to support the flow clone + use, and then we need a URL |
Added Name |
oss-recipes-repository
featurelocal-recipes-index
feature
Instead of requiring a local clone in the filesystem, could this allow me to specify just a git URL? For example:
With this setup can I have recipes in git and binaries in Artifactory? |
We have considered, even implemented it, and reverted. A couple of reasons:
So it was just like creating a more limited, poorer layer over
Yes, Conan 2 binary management allows to use recipes from one repo (including this new local-recipes-index one) and binaries from other repos, because using revisions everywhere to guarantee consistency it allows to do so and guarantee that the binaries from one repo belongs to the same source recipe (recipe revision). Note that when binaries are uploaded to Artifactory, the recipe is also uploaded there together with the binary, so once this happens, it is no longer needed to use both and users can also get recipes and binaries from server repo too. This would be a very typical setup, and we already have many users that are doing this approach, even without the |
Vcpkg suggests consuming projects add vcpkg as a git submodule. Would that pattern work with the mechanism you are building here? Let's say my company maintains a fork of conan-center-index at https://github.com/acme/conan-index.git that is extended also to contain our own libraries. Could consuming applications then add that as a git submodule and use that as the repository as the source registry and then artifactory would only be used for binary packages? |
Yes, this would work with this new
The local-recipes-index is intended for third party libraries. For packaging your own libraries, the approach of putting the |
Changelog: Omit
Docs: Omit
Not documenting the feature until the blog post that announces it
How to use it: