I'm very much in favor of breaking up charm helpers as well. I think it
ultimately acknowledges how charm developers have chosen to use the library
(even if not quite correct), but also allows for a theoretically more
organized core library. A few thoughts come up as I read this...
First, the hook
I am very much in favor of this move forward. I’ve recently worked on
converting the charm-benchmark package to charms.benchmark; I see where having
cleaner namespaces make will make every charm author’s life easier.
That said, I know that transitioning to this new model is an epic undertaking,
Hello everyone,
I'm rebooting this conversation because it never fully came to a resolution
and since this topic was discussed a lot has happened in the Charm
Ecosystem. I still hold firm, and a lot of charmers I've spoken with agree,
that charm helpers has become the opposite which it originally
Hi Cathy,
These messages are used to indicate why the service is not a fully
functional service.. As you point out, the software packages for the base
charm service has been installed at this point in time, but needs
additional relations in order to make the service a fully functioning
service. Th
