Issue #7270 has been updated by Daniel Pittman. Tracker changed from Refactor to Bug
> Daniel, is it possible to get a summary of the negative aspects of the > current implementation, particularly as it would affect Face developers and > users? At the moment the "global" options are implemented by using the legacy application option processing system. This means that: * can't be introspected, unlike the other options * don't have the same hooks for documentation, etc * don't show up in the help output * have a block that can do arbitrary things, which works once, rather than like other options do That said, the only real way to add a "global" option is to hack into the face_base application, or their wrapper application, so end users are *really* not that likely to run into this. They probably won't be running into anything except the lack of documentation of it... The biggest problem is that they are not uniform in a lot of ways, like the introspection / help thing, so as we add more features they won't be found in the few global options we have... ---------------------------------------- Bug #7270: unify global options with face and action options... https://projects.puppetlabs.com/issues/7270 Author: Daniel Pittman Status: Needs Decision Priority: Normal Assignee: Nigel Kersten Category: Faces Target version: 2.7.1 Affected Puppet version: development Keywords: Branch: At the moment we handle global options for faces in a ... different way. They are basically the old fashioned application options, kind of vaguely repurposed to do something approximating the right thing. We should unify the behaviour of those, ideally along with options derived from our configuration system, and make them all behave consistently. This would naturally want to involve unification of the DSL for declaring options, and in turn for introspection of them: that would make it practical to have them in the help output, and so forth. Which is desirable, especially round the area of option validation. It also means we can unify error handling, so that we don't have some classes of validation resulting in good help output, and others resulting in bad help output, just because they are handled by different substrates in the product. -- 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.
