One more chunk of feedback, I think conversations like this can/should happen on the main juju list. I know folks dump to dev a lot, but this is something very public facing and has an impact on users.
On Thu, May 26, 2016 at 6:46 AM Rick Harding <[email protected]> wrote: > Some feedback > > If we have a debug command we should just show the debug commands. If we > don't want users to have them ootb they should be plugins then I would > think. This assumes the commands can't do anything destructive or > otherwise harm a running model/etc by being run. > > The get is there because of the set. Some things are read/write properties > and those are get/set. list vs show is meant to be around entities in the > Juju model. You can list them to see tabular output of info about the > entity and you can show them for single details. I appreciate the config > case seems odd, but config isn't a root model entity, it's a property and > you can set that and you can't set other entities in the model. I think it > makes sense to keep these. > > The list one is tricky. list is there to be consistent, help users > discover entities in the model (list-<tab>), and to help easily see things > in the help text as it jumps out as a common pattern (you can list, show, > etc things). However, it was agreed that leaving off the list should > default to the list output. It reads nicer and seems to make the most sense > for users that know enough Juju to know what they're doing. > > With that in mind, hiding them behind an --alias or what not seems counter > productive. It's not there in the main output for new users, the ones we're > aiming to serve. With this in mind, it makes the most sense to just remove > them then, which I don't personally like, but I think makes things the most > clean and with the most consistent story. > > On Wed, May 25, 2016 at 2:52 PM Nate Finch <[email protected]> > wrote: > >> +1 ... one and only one way to do something is a lot easier to >> understand. Either we like juju list-foos or we like juju foos... pick one >> and move on. This feels like two camps agreed to disagree and just kept >> both. >> >> On Wed, May 25, 2016 at 10:12 AM Katherine Cox-Buday < >> [email protected]> wrote: >> >>> >>> I think this has come up before on this list, but: isn't having 2 sets >>> of commands in the first place a design smell? If we need aliases because >>> users aren't using the originals, then shouldn't we fix the original >>> commands? >>> >>> Tim Penhey <[email protected]> writes: >>> >>> > On 25/05/16 00:12, Marco Ceppi wrote: >>> >> Even if you don't expect people to run them, hidding them seems >>> >> awkward. >>> >> Better to simply educate with good help output about what the >>> >> command >>> >> does and when/why use the command. >>> > >>> > Was thinking, perhaps it would be better to have a feature flag to use >>> > the "hidden" commands instead of the ability to hide commands. >>> > >>> > If you set the feature flag, you get the additional commands, and they >>> > show up in help etc. That way a way to get users to run them could be >>> > something like: >>> > >>> > JUJU_FEATURE_FLAGS=dev-debug juju dump-model >>> > >>> > or something like that. >>> > >>> > Tim >>> >>> -- >>> Katherine >>> >>> -- >>> Juju-dev mailing list >>> [email protected] >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju-dev >>> >> -- >> Juju-dev mailing list >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
