The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:
Faces cannot add subcommands when distributed as a module
|Assignee:||Jacob Helwig||% Done:|
|Affected Puppet version:||2.7.3||Branch:|
|Keywords:||faces subcommand command action module|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
Faces that add a new subcommand to Puppet are not functional when distributed as a module. Faces that add actions to an already existing subcommand in Puppet core (e.g.
node) are functional, however, and a puppet module may add additional actions.
Puppet Modules should have the ability and functionality to add additional sub commands using the Faces API.
Only sub commands which ship as part of Puppet core are able to have additional actions included as Puppet Modules. The addition of a subcommand must be done by modifying
$RUBYLIB (environment variable) or
$LOAD_PATH (ruby global variable).
Talking with Daniel in ad-hoc conversations this is way more complex and entangled than it initially may seem because of how entangled the configuration file parsing and command line option parsing are. Puppet must first fully parse puppet.conf and the command line arguments to determine the module search path before initializing the Faces API to search for available sub commands and actions. This presents a difficult chicken and egg problem.
Possible work around: Make the
modulepath option “special” and modify
$LOAD_PATH early in the framework initialization?
#1 Updated by Anonymous over 4 years ago
- Subject changed from Faces are not functional when distributed as a module to Faces cannot add subcommands when distributed as a module
- Status changed from Unreviewed to Needs Decision
Nigel, I think we need to decide if this functionality should ship in CK or not. It’s not required for Cloud Provisioner since that module adds actions to
puppet node which is part of core, but it would really nice to have.
#2 Updated by Nigel Kersten over 4 years ago
- Status changed from Needs Decision to Accepted
- Assignee changed from Nigel Kersten to Jacob Helwig
- Target version set to 3.x
This is one of the biggest goals I have for Telly, and I believe it’s compatible with the work Jacob’s team were trying to get done on fixing pluginsync in general.
This issue may be a duplicate, but we need to spend some time working out what all the plumbing changes are that are required, and whether this particular goal will be hit for Telly.
I’ve assigned to Jacob in case he has a comment, but from my understanding we need to fix the puppet bootstrap process so we have cleaner separation, and do a bunch of work around the autoloader to bring consistent semantics there.