Issue #6750 has been updated by Daniel Pittman.
Luke Kanies wrote: > Daniel Pittman wrote: > > > > I care much less about that, and much more about the fact that these highly > > position-sensitive options cause me trouble every time I hit a tool that > > uses them. I don't think they are a big win for the interfaces work, if we > > can possibly avoid them. > > Hmm. It's true that I haven't tried a ton of commands with this style of > option handling and it might be confusing. I'd prefer to turn it on and > actually put it in front of users, and if at all possible, we should build > something that can be switched between modes relatively easily. Well, anything that attaches options in a detectably distinct context for each command would work, but it might be easier to produce a mock-up that does both, or maybe involve Randall in this to see if our UX guy has an opinion. ...or maybe survey people? Getting real feedback would be great, though. > > One other problem I can see is, in essence, how would you envision passing > > this in a richer data structure? It would be good to think about mapping > > these to, say, RPC calls, or messages, and that gets kind of confusing when > > the target is a single "action", but we need to pass options to multiple > > places? > > In some ways this is exactly why I want this form of option handling -- there > are some options that only make sense on the CLI, some that would only make > sense in the REST interface, etc. We need a clean mechanism for managing > these sets of options and allowing specification by both the developer > creating them and the user consuming them. ...but this has nothing to do with CLI vs REST passing of options, which is actually *easier* in the flat GNU style version, as far as I can see. To implement the POSIX "order matters" bit in an HTTP context we would need to define something that separated out *which* part of the invocation you were trying to reach, or generate a URL that embedded it. GNU style options, though, map naturally to CGI parameters, or to POST body form-style parameters. Nice, flat, simple, and easy. At the cost of being unable to have `-v` mean two different things in two different places, which I would frankly consider to be a win for usability anyway. > If we can do that easily and treat all options equivalently, then maybe > POSIX-style handling is the wrong step. Maybe your last comment wasn't actually disagreeing with me? Er, I think so, and that it is a very reasonable process to allow us to define them. In another ticket there is a proposal to embed some argument validation and coercion into the option configuration. That gives us a solid hook to allow introspection of this data, and to build non-CLI interfaces, I think. As a concrete proposal, if we deliver GNU style options, and then add POSIX options when a use case that demands them pops up, would that be acceptable? I can't identify any use case when I think about how these things are used, or what I would do with them, so don't want to build something to meet "maybe", but perhaps you do have something in mind that I am not aware of which this enables? ---------------------------------------- Feature #6750: Interfaces need to support "posix style" option handling https://projects.puppetlabs.com/issues/6750 Author: Paul Berry Status: Accepted Priority: Normal Assignee: Category: interfaces Target version: 2.6.x Affected Puppet version: Keywords: Branch: Posix style, in this context, means that Puppet needs to distinguish between options specified in three possible locations: puppet <a> interface_name <b> action_name <c> Options at location <a> are intended to be global options (those applicable to all Puppet interfaces and actions, like --debug) Options at location <b> are intended to be interface-specific options Options at location <c> are intended to be action-specific options. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
