Determine a CPAN namespace for Rex recipes about rex-recipes HOT 2 OPEN

FTR, we reached the following conclusions on IRC:

Core ideas

We'd like to make a distinction mainly between:

• packages that alter the behavior of Rex itself or add new capabilities (extensions, plugins, hooks, commands)
• packages that uses Rex to manage a specific software or service (modules, recipes)

Therefore we believe different namespaces would work best to make these distinctions clear. Having a common namespace makes it easier to find them too (e.g. by searching on CPAN or GitHub).

Examples

Extending a core namespace

Rex core is modular enough to be extended to support new functionality without having to change the core itself. A great example is the Rex::Virtualization namespace to interact with various virtualization solutions.

This makes adding new capabilities and maintaining them easy by the community (for example Rex::Virtualization::CBSD), and also makes great candidates to split out of core (not every user of Rex needs all the virtualization modules, and their maintenance could be decoupled from core).

Other examples include Rex::Commands, Rex::Hook and Rex::CMDB namespaces. If some of those third party extensions become stable and useful enough, it is also possible to integrate them into core directly (taking future maintenance burdens and benefits into account).

Where core might not be generic enough yet for this pattern, we'd like to help community member's efforts by enabling them to integrate with Rex in a better way (e.g. by modifying core that enables better integration).

Extending Rex outside core namespaces

We believe the names "extension" and "plugin" are synonyms, and they both extend Rex core with new capabilities. If they really need a new namespace that is not present in core yet, we recommend using Rex::Plugin.

Already used Rex::Ext is short but doesn't seem to be clear enough, and Rex::Extension feels too long, while both has repeating "ex" which might be hard to use in speech.

Managing software and services with Rex

When Rex is used to implement management steps for a given software (e.g. Rex::Lang::Ruby) or service (e.g. Rex::Webserver::Apache), we used to call that a "recipe". Rex::Recipe looks duplicate and Rex::ipe/Rex::Ipe sounds fun, but not descriptive enough.

Currently we recommend using Rex::Module namespace for those, for example Rex::Module::Apache, Rex::Module::Ruby.

EDIT: but also see the next comment.

Since Rex already hides the Rex prefix for task names, this results in CLI calls like rex Module:Apache:configure or rex Module:Ruby:setup. If needed, the Module prefix can also be hidden, probably upon explicit request in the code. This additional hiding behavior could even be made configurable, or a "shortest unique form" can be used for finding task names.

Using site-specific Rex modules

When the utility of a Rex module is specific to a given site (e.g. Company, Inc.), Rex::Company namespace feels like a natural fit. This pattern still keeps it easy to optionally publish these modules for the wider community later, by simply search-and-replacing ::Company with e.g. ::Module.

from rex-recipes.

Currently we recommend using Rex::Module namespace for those, for example Rex::Module::Apache, Rex::Module::Ruby. Since Rex already hides the Rex prefix for task names, this results in CLI calls like rex Module:Apache:configure or rex Module:Ruby:setup. If needed, the Module prefix can also be hidden, probably upon explicit request in the code. This additional hiding behavior could even be made configurable, or a "shortest unique form" can be used for finding task names.

After playing with the Rex::Module:: prefix for a while, I think it's nice to use it as a grouping method, but it's also not mandatory in any way. While this special namespace handling may be implemented, feel free to go ahead and use e.g. Rex::Apache for a generic-purpose Apache management module based on Rex (or keep Rex::Webserver::Apache).

IMHO the more important thing is to fit standard CPAN naming conventions, and to avoid potentially hijacking a whole namespace if a module is only going to implement a narrow subset of a problem domain.

from rex-recipes.