As mentioned on another thread, searching will only include stable charms’ releases. The fact that this is done implicitly and in a non-modifiable way is confusing and frustrating if you’re looking for a charm with only edge, beta or candidate releases.
I think that this is working as intended. In principle, the search results in CharmHub should only include stable, reliable charms that can be relied on for production use. Things are imperfect in practice, of course, but we want to be heading toward perfect, rather than away from it as CharmHub matures as a platform.
For charms that are in development by teams at Canonical, I usually take a look at our organization’s Teams page on github. That gives me an idea of what charms are available. And there’s nothing to prevent me, once I have a name, from deploying or downloading the charm via the CLI, or just typing in the charmhub url manually.
the search results in CharmHub should only include stable, reliable charms that can be relied on for production use.
I think “ready for production use” is not such a black and white distinction as we’d like it to be. To me, the point of having different channels is not only a developers’ feature but also a users’ one. A user could need a feature yet not published as stable but he’d be willing to “take the risk” of installing something on edge or beta to get that feature earlier. He’d be knowingly taking that risk because he’d know he’s not installing from stable.
Letting that use case aside, I believe having the search include all channels as an opt in feature would be useful for contributors and would not affect users of production systems.
1 Like
Hey @pengale. I appreciate the feedback. I think that curating a view of production-ready/stable charms via the GUI is a great way to keep charm consumers within a walled garden of safety.
However, as a charm developer, whether at Canonical or external, whether new to the environment or a seasoned charmer, it’s critical to be able to query registered namespaces in a fuzzy manner to avoid duplication of effort across the community when a charm is working toward it’s first stable release.
I feel it would be sufficient to address this concern in the charmcraft CLI to query registered namespaces in a fuzzy manner similar to “snap search” and “apt-cache search” rather than alter the curated view of the charmcraft web UX.
@mcjaeger hi there, this topic might benefit from your expertise and knowledge of the charms currently in Charmhub 