Closed cjserio closed 1 week ago
Hi @cjserio
Thanks for your question.
We have written a section in the docs about how to use ConanCenter packages in different "production" scenarios: https://docs.conan.io/2/devops/using_conancenter.html
A very extended and recommended practice, because many organizations for example cannot use binaries from the internet, is to create your own packages and use them from your own private repository in your organization, check https://docs.conan.io/2/devops/conancenter/hosting_binaries.html. This way, having your own jwt-cpp/0.7.0-pre.1
or something like that with your patches is straightforward, and your organization will resolve against your repository (recall there are tools like conan config install
that allow to configure organization-wide the remote repositories to be used). This approach has some other important advantages, explained in those docs sections, please have a look and let me know if it helps.
Hi @cjserio
Did the above clarify things a bit? Let us know if there is any further question. Thanks!
It did! What I did is I made a mirror of conan-center-index and then cloned it locally, found the recipe and added patch files to it, then edited the conandata.yml to reference the patch files. I commit these changes to our local git mirror. Then I run conan export on that recipe. In the case of binaries, I then build the recipe and then upload everything to our artifactory server.
Is this the right flow of things or is there a more efficient way of doing this? The 'conan export' step feels weird/unnecessary. It feels like there should be a way for conan to know about the git mirror of conan-center-index the same way it knows about the actual conan-center-index.
So am I doing something wrong or is it just a limitation?
Is this the right flow of things or is there a more efficient way of doing this? The 'conan export' step feels weird/unnecessary. It feels like there should be a way for conan to know about the git mirror of conan-center-index the same way it knows about the actual conan-center-index.
Yes, this is the local-recipes-index
feature, please have a look to: https://docs.conan.io/2/devops/devops_local_recipes_index.html
I think it is basically that, avoiding the manual conan export
step, doing it automatically when needed from your fork. I didn't introduce it earlier above, because the important bit is to understand the fork and custom patches model on source, the local-recipes-index
is a bit of automation on top of that model.
Ah! Yes I saw that too but it's 'local' only. I guess I still expected to be able to distribute a conan config to developers that pointed all of their conan installations to the GitHub mirror instead of conancenter so that I knew that they could only ever get recipes from the mirror and so that we had complete control of the process. I know we get that through our artifactory server but if they want to add their own recipe that's not already on the server, it's going to default to getting it from conancenter which might confuse things. I've tried to be diligent and add a "user" to the identifier for recipes that we've had to modify so that they can't accidentally get the wrong versions of those.
The rationale for it is more or less explained in https://docs.conan.io/2/devops/devops_local_recipes_index.html#using-local-recipes-index-repositories-in-production
Basically, when running from source forks, the norm will be running on some branch, commit, tag or even from source without committing it.
Maybe you are interested in --allowed-packages
feature, see https://docs.conan.io/2/reference/commands/remote.html#conan-remote-add, where you can restrict which packages comes from which repository.
Any further question here @cjserio?
Did the --allowed-packages
help?
I didnt' end up using allowed-packages but the rest of the information is useful, thank you!
Great. I think we can close this ticket as responded then, if there are any further question you can re-open or create a new ticket. Thanks for your feedback!
What is your question?
I know this must be a common use case and question and I did search but I feel like there are many ways of doing what I'd like to do and I'm not sure what the "preferred" way is.
Out project depends on JWT-CPP but the most recent version is 0.7.0. About 7 months ago I submitted a merge-request to their GitHub project and it was accepted but they haven't released a new version yet.
So what I'd like to do is set my own project's recipe up to depend on version 0.7.0 PLUS the addition of the patch file that I have. This needs to work for all of the other engineers on my team too so it can't just be a local solution..it needs to be something everyone can easily apply.
What's the recommended way to do this?
Have you read the CONTRIBUTING guide?