The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Refactor #13336

explore improvements to Puppet::Application life cycle accessibility / method names

Added by Chris Price about 2 years ago.

Status:AcceptedStart date:03/22/2012
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:API
Target version:Waldorf
Affected Puppet version: Branch:
Keywords:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This ticket may be automatically exported to the PUP project on JIRA using the button below:


Description

Currently, the life cycle of a puppet app is roughly expressed by the following series of method calls:

  • CommandLine#parse_global_options
  • CommandLine# (parse configuration file—this isn’t actually expressed as a method of CommandLine but probably should be, for accessibility)
  • Application#initialize_app_defaults
  • Application#preinit
  • Application#setup
  • Application#configure_indirector_routes
  • Application#run_command

My concerns around accessibility are mostly related to the possibility that people will need to trigger individual phases outside of the normal execution chain (even if only for testing).

My concerns around naming have to do with the fact that many (perhaps most) of these methods can be overridden by subclasses to Application (or faces), and based on the names alone it would be almost impossible for a caller to guess what the order of execution would be. We’ll probably never get to a point where the names are clear enough to be completely intuitive without the caller needing to rely on documentation, but they could probably be more clear than they are right now.

If/when we introduce name changes we’ll need to make sure to keep backwards-compatible signatures around for some period of time, and log deprecation warnings… so that we won’t break third-party puppet applications.

Also available in: Atom PDF