(PUP-5561) Clarify rules for autoloading puppet functions

[hlindberg]

This adds language to the puppet-functions.md that clarifies the rules for naming puppet functions and how autoloading and ad-hoc manifest defined functions work.

[nfagerlund]

This PR does not mention the magical environment:: namespace, which to me was the single most confusing and surprising thing about this behavior.

It also does not mention that the functions/init.pp file is never loaded, or explain why that's the case. (Or, if it is loadable, what circumstances cause it to be loaded.)

[hlindberg]

I thought it did mention 'environment::' name space. Although in a terse way as this is a specification after all. Will re-read.

I don't understand the question about "function/init.pp" file never being loaded. Naturally if there is a function named mymodule::init(), and you call it, it will be loaded (from "mymodule/functions/init.pp". If you call another function mymodule::foo(), it will load the mymodule/functions/foo.pp file, but not the mymodule/functions/init.pp file. Is this perhaps a confusion over if just saying "init.pp" is a reference to "manifests/init.pp" or "functions/init.pp" (which is an ambiguity I had not considered). If so, then just clarifying that distinction should clear that up? Or, did I misunderstand the question?

Calling a function will load it if it isn't already loaded (i.e auto loaded if not already defined). Loading has no other side effect (nothing else is loaded; neither from manifests nor from functions).

[nfagerlund]

Ah. You mention the environment:: namespace under what "should" (but not "must") happen when loading functions from the manifests dir, but you do not mention that it's mandatory in order to AUTOLOAD anything from an environment's functions dir.

We need that info in the spec.

[nfagerlund]

Naturally if there is a function named mymodule::init(), and you call it, it will be loaded (from "mymodule/functions/init.pp".

This is a radical departure from the behavior of the normal (class / defined type) autoloader. In that autoloader, it is illegal to have a class named <MODULE NAME>::init, and manifests/init.pp should contain a class named <MODULE NAME>; however, if a class named <MODULE NAME>::<SOMETHING> is not found in manifests/<SOMETHING>.pp, init.pp will be loaded in an attempt to find that class. In (what I guess I'll call "the function autoloader, distinct from the normal autoloader"), init.pp—

• is not special
• will not be loaded when attempting to find a function named <MODULE NAME> or environment
• will not be loaded as a fallback when attempting to find a function named <MODULE NAME>::<SOMETHING> or environment::<SOMETHING>

This info is missing from the spec.

[hlindberg]

Updated PR.

[nfagerlund]

Excellent, this resolves all my problems. :+1:

[igalic]

a few things are still kinda missing imo:

• is there a possibility to declare the return type?
• is the return value (like in ruby), simply the last value in the block?
• a full example, or two…

[hlindberg]

Thanks igor; good points. No return type declaration possible atm. And yes, last evaluated expression in any block/sequence is the result.

I may forget to update this in the spec unless there is a PUP task type ticket for it ;-)

• henrik

12 dec 2015 kl. 15:29 skrev Igor Galić notifications@github.com:

a few things are still kinda missing imo:

is there a possibility to declare the return type? is the return value (like in ruby), simply the last value in the block? a full example, or two… — Reply to this email directly or view it on GitHub.

[igalic]

@hlindberg PUP-5602