Skip to content
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

[question] How to limit "conan list" to remote only #17380

Closed
1 task done
rafzi opened this issue Nov 26, 2024 · 5 comments
Closed
1 task done

[question] How to limit "conan list" to remote only #17380

rafzi opened this issue Nov 26, 2024 · 5 comments
Assignees

Comments

@rafzi
Copy link

rafzi commented Nov 26, 2024

What is your question?

I'm using a command like the following and would expect that this allows me to check the existence of the packages in the remote.

conan list --graph=build.json -r MyRemote

However, it returns the packages in "Local Cache".

If I just use the following, it seems to work correctly.

conan list "name/version#rrev:pkgid#prev"
# returns "Local Cache" result
conan list "name/version#rrev:pkgid#prev" -r MyRemote
# returns "MyRemote" result

Q: Is there any way to query the remote for the packages in the build.json (from "conan create --format=json")?

Have you read the CONTRIBUTING guide?

  • I've read the CONTRIBUTING guide
@memsharded memsharded self-assigned this Nov 26, 2024
@memsharded
Copy link
Member

Hi @rafzi

Thanks for your question.

When using the conan list --graph=graph.json, the -r=remote argument is fully ignored. I think this is mostly an UX issue/bug, and the right behavior would be to raise an error saying that the -r argument doesn't apply in this case.

Q: Is there any way to query the remote for the packages in the build.json (from "conan create --format=json")?

There is no way, because the result of graph.json can only contain local packages, because that is the result of a "graph" operation, and graph operation needs to download the recipes and packages, so conan create --format=json and conan install --format=json, will have all the packages always in the Conan cache, not in the remotes.

What is your use case, what are you trying to achieve? The conan list --graph flow is mostly useful for uploading packages that were built locally.

@rafzi
Copy link
Author

rafzi commented Nov 27, 2024

Thanks for the quick and detailed response.

You are right that it does not make much sense with create or install because the graph content is guaranteed to be in the cache.

The basic idea is to follow this concept to host own binaries: https://docs.conan.io/2/devops/conancenter/hosting_binaries.html

An issue with the described flow is that if the local cache is lost, e.g. when a CI machine is reprovisioned, all packages are rebuilt from scratch even if they still exist on the remote. So the idea was to check whether a remote has binaries available for the given configuration and only if they do not exist, build and upload the package. I also tried "conan graph info", but that does not give me PREVs if the packages do not exist in the local cache.

Is there any way to achieve this?

@memsharded
Copy link
Member

An issue with the described flow is that if the local cache is lost, e.g. when a CI machine is reprovisioned, all packages are rebuilt from scratch even if they still exist on the remote.

I might be missing something, but this shouldn't happen. If the packages are in the remote, they will be used from the remote, binaries are downloaded from the remote by default in all install operations. If you are using conan create then you might need to add --build=missing for this specific flow to avoid force-rebuilding when not necessary.

@rafzi
Copy link
Author

rafzi commented Nov 28, 2024

Sorry for the confusion, everything seems to work as expected. conan create --build=missing only builds packages not already found on the remotes, then builds if anything is missing. A subsequent conan upload only uploads what was missing.

I thought it would maybe be possible to get around the downloading step, but that does not seem worth any additional effort.

@rafzi rafzi closed this as completed Nov 28, 2024
@memsharded
Copy link
Member

Nice, not a problem, happy to help, thanks for the feedback!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants