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
pool: Offer API to look up by bundles #457
Conversation
So, you want an API like Or do you want an API like the one in this PR that just takes |
|
FYI, there will be a new AppStream release this Thursday, in case you do want to get this change in by then. |
|
No, I do not want the component id, just the bundle id. In fact, part of the problem is that sometimes we know the flatpak bundle id but not the component id.
That. Which is what this wants to do. |
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.
Okay :-)
Do you think you'd ever want some "fuzzy matching" for bundle IDs? (I don't think so, but just in case, so we don't need to adjust public API again later).
Also, a bunch of comments on the code ;-)
|
|
||
| return result; | ||
| } | ||
|
|
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.
this needs a GIR wrapper, like the one below too... But I could add that as a follow-up commit, if you don't want to dive into writing binding code.
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.
Please, I'd appreciate it if you could look into this later.
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.
It's quite trivial, so, no problem :-)
81c6592
to
9589459
Compare
I can see the use-case for wanting to match I don't think we need more flexibility than that, but considering here we are supporting different formats from flatpak, I'm not sure we can come up with a simple API to cover this other than the wildcards. |
|
The problem is that I don't think libxmlb supports wildcards to match text strings... It can fuzzy-match strings as described in https://github.com/hughsie/libxmlb/blob/567d261706add40cbe6a5acbd2a3f504b80449de/src/xb-string.c#L141-L147, but doesn't have support for wildcards for node text content. I think the best we could do, and which might probably even work here, is do an optional prefix match instead of an absolute match (so the input would be |
50bf428
to
af79541
Compare
It's often that we will need to look up packages by their name. Include some API that helps us do it.
af79541
to
3966612
Compare
It's often that we will need to look up packages by their name. Include some API that helps us do it.
WIP because it would be necessary to look up by e.g.
org.kde.dolphintoo, not justorg.kde.dolphin/x86_64/master. Some idea on how to do this would be useful.Context for this change is here:
https://invent.kde.org/plasma/discover/-/merge_requests/455