Open AdamIsrael opened 6 years ago
AdamIsrael
commented
6 years ago An additional use-case: I've discovered an interface published in the layer index that has been implemented backwards (using requires instead of provides). I want to see what charms have implemented it (possibly having reversed the relationship endpoints), so that I can plan on fixing or replacing the interface to correct the error.
johnsca
commented
6 years ago Unfortunately, until https://github.com/juju/charm-tools/issues/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.
rogpeppe
commented
6 years ago @johnsca I just replied in https://github.com/juju/charm-tools/issues/404#issuecomment-430560364
rogpeppe
commented
6 years ago 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:
GET https://api.jujucharms.com/charmstore/v5/search?provides=http&limit=20
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.