-
Notifications
You must be signed in to change notification settings - Fork 37
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
Reverse Dependency lookups #852
Comments
An additional use-case: |
Unfortunately, until juju/charm-tools#404 is done (and even then, only for updated charms pushed to the store after that becomes available), this information isn't readily available even on a per-charm basis. It can be reconstructed from the top-level includes, but that involves walking through and even fetching all of the included layers to collect them. Once the linked issue is addressed, then we could easily find out for a single charm what layers were used by checking the build manifest, but we would still need to create a back-reference table for this info to be queried efficiently. Ideally, that back-reference table could be queried via the charmstore API and would be kept up to date by the charmstore as charms are pushed, but it might also be conceivable to have it be external and updated by the charm command instead. |
@johnsca I just replied in juju/charm-tools#404 (comment) |
Currently the charm store does not know anything about layers (they're considered an internal implementation detail of charms). However it's possible to search for implementations of a given relation interface by doing a search for "provides"; for example:
|
I'd like to propose a new feature: reverse dependency lookups.
Use-case:
A developer wants to find charms that implement a specific layer or interface.
As a charm developer, we write layers and interfaces to be reusable components. We have the layer index to see a list of these, but it's often useful to see how they're being implemented (because too many lack documentation).
If we have a reverse dependency API, we could offer a way to see how those components are being used. This is useful from a metrics perspective, to see by whom and how these components are being used. It also aids developers looking for functional examples, which is always a bonus.
The text was updated successfully, but these errors were encountered: