Issue #15206 has been updated by eric sorenson. Assignee changed from eric sorenson to Ashley Penney
This is definitely an interesting idea. I have had this problem myself. I wonder if, rather than changing the DSL, it would be possible to simply extend the comment parsing in `puppet doc` to include a `Visibility` header or the like; then UIs which cared (the html generated puppet doc output, ENC display, etc) could get hints about how to display the class but the parser/compiler wouldn't need to change. Ashley would that suffice? or do you think there are _language-level_ changes that are needed to make this work for you? ---------------------------------------- Feature #15206: Ability to hide classes from an ENC/UI https://projects.puppetlabs.com/issues/15206#change-69079 Author: Ashley Penney Status: Needs Decision Priority: Normal Assignee: Ashley Penney Category: modules Target version: Affected Puppet version: Keywords: Branch: Hi, For a while now I've been wishing I could mark classes as hidden in some obvious way that makes it clear to the reader that this class is not supposed to be included on a node but only via other classes. While there are ways this could be hacked up today (checking a puppetdoc at the top etc) I'd prefer for it to be an official part of creating a class. Something like "internal class blah { }". Ideally this feature wouldn't -stop- you from including it on a host, just provide a mechanism by which the dashboard/foreman/other ENCs could hide this class from a user. My use case is as follows: I have three modules. Cman, Corosync, Pacemaker. None of these modules are really usable by themselves. Between them they have -14- classes. These are the normal corosync::params and pacemaker::config and other kinds of classes you'd expect to see. When users are assigning classes to machines I only want them to be able to attach one single class from the above 14 - cman/manifests/init.pp. I would love to be able to mark the others as "you shouldn't really attach this to a host" as a way of decluttering the interface. It would also assist in showing how a module "should" be used when encountering it for the first time. If you spot that two classes are public and the rest are private then you have a great starting point for understanding how to assign them to nodes. -- 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.
