[PUP-7181] Add a find_function(name) function Created: 2017/02/06  Updated: 2017/05/31  Resolved: 2017/05/17

Status: Closed
Project: Puppet
Component/s: Language
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Normal
Reporter: Sean Millichamp Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Team: Puppet Developer Experience
Sprint: Forge - To Accept
QA Risk Assessment: Needs Assessment

 Description   

The defined() function should be able to see if a given function name is defined for both Ruby and Puppet Language functions.

Example:

defined('digest()')
 
defined('mod::func()')



 Comments   
Comment by Henrik Lindberg [ 2017/02/07 ]

What purpose would this serve? You would know the same by knowing the version of puppet, and the version of the modules a module's depend on. Wouldn't it be better to be able to ask for the version of a module ?

Also, when just asking if a function is defined, that may not be enough as its signature may have changed between versions.

I like to better understand the motivation behind the request to add this. Sean Millichamp, can you elaborate?

Comment by Henrik Lindberg [ 2017/02/07 ]

I can imagine other ways of doing the same thing - basically being able to "get" the function, and then see if that matches a particular Callable, or if it is undef (not found). A function that is obtained that way, could then also be called (there is a PR for a call function) that should have the ability to call any callable instance.

Such a "get" could be named something like "find_function".

Comment by Sean Millichamp [ 2017/02/09 ]

A "find_function" approach would be great too.

Good point about function signatures. For my purpose I was assuming that the signatures would not be an issue.

The motivation is that we have some early manifest bootstrapping logic which can (and does) vary per customer. Traditionally we have baked that all into one massive case statement in a single class that is the first thing we load. This had the downside of being difficult to maintain, test, manage, and certainly not nimble enough for others (less familiar with the code) to contribute new logic for new customers in a timely manner.

I am currently reworking this logic to instead allow a Puppet language function to be written outside of the core module and then have which function gets called (via `call`) using a configurable setting (typically via a lookup in Hiera). This would permit the team to craft and deploy a custom function for a new customer in a rush situation outside of the change control process our core (versioned) code is required to follow.

My thinking here was to check for the existence of the requested function and, if not found, either soft-fail (allow the catalog run to complete, raise an error via Notify, but skip most of the processing) or hard fail with an error that would provide additional help/site-specific direction to the user. Definitely in the "nice to have" category rather than required for this use case.

Also, in my situation the most likely spot where these functions would appear won't be in versioned modules (either via git tag or a metadata.json-supplied version) so in this case I actually couldn't check for either.

Comment by Moses Mendoza [ 2017/05/17 ]

Thank you for filing this issue. However, we believe this change represents a technical direction that we have decided not to follow in Puppet. As such, we are closing this as “Won’t Do”. If any watcher believes this is an error, please add a comment explaining.

Generated at Sat Dec 07 21:14:14 PST 2019 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.