On Wednesday, January 22, 2014 12:15:31 PM UTC-6, henrik lindberg wrote: > > Recent Pull Requests to puppetlabs-stdlib has raised issues w.r.t how we > should handle stdlib going forward. We have also had a discussion about > types and providers in core and if they should be moved out to modules > in a "tier2". That discussion also raises issues about > backwards compatibility, and configuration of modules. > > I am posting this to trigger a discussion and to collect requirements. > > * Is there content in stdlib that really belongs in core? >
That begs a more fundamental question of policy on what kinds of things belong in core in general. Also a question of whether there's a distinction between "core" and a hypothetical "tier1" that isn't the core product but is developed and maintained by PL and packaged with core. With that said, there are many functions in stdlib that seem strangely placed in an optional add-on module. Functions that I would definitely put in that category include empty() flatten() get_module_path() has_key() is_array() is_hash() is_numeric() is_string() join() keys() size() values() Other functions that I might suggest putting in that category include abs() any2array() concat() count() delete() delete_at() delete_values() delete_undef_values() difference() dirname() floor() fqdn_rotate() hash() intersection() join_keys_to_values() lstrip() max() member() merge() min() pick() prefix() range() reject() reverse() rstrip() sort() squeeze() str2saltedsha512() strip() suffix() type() union() unique() values_at() zip() There are also some functions whose usefulness, I question, but which, if indeed generally useful, probably should not be optional add-ons: bool2num() capitalize() chomp() chop() downcase() getvar() grep() is_bool() is_float() is_integer() num2bool() shuffle() str2bool() strftime() swapcase() time() type() upcase() uriescape() * Is there content in stdlib that should never have been included (it > should really be in a different module)? > Anything in my third list above might fall into this category. In addition, I would definitely put any stdlib function not already listed above into this category. In particular, although I see the validate_*() functions serving a useful role, I think don't see them as core, and moreover they would hang together nicely in their own module. Likewise, there is a group of functions centered on probing nodes' network characteristics; these also don't seem quite "core", but do hang together as their own group. There are a few oddball functions that perhaps hang together loosely, but that don't feel "core"-ish to me: base64(), loadyaml(), parsejson(), parseyaml(). And then there is a handful of functions that should not exist: Those certainly should not be considered "core", and the only reason I see even for keeping them in stdlib is to avoid breaking third-party modules: defined_with_params(), ensure_packages(), ensure_resource(), getparam(), is_function_available(). Really, these would be better in a "dangerous_hacks_you_should_not_use" module, just to make it clear. > * How do we keep stdlib in sync with the Puppet version? > Is it necessary to do so? Few of its functions seem dependent on Puppet internals, and none of those are among the ones that I think clearly belong as part of the core product. Most of those dependent on Puppet internals are in the group "dangerous_hacks" group. Yank those out, I say, and make them somebody else's problem. > * How should module authors deal with their dependency on stdlib? > What sort of "dealing" are you asking about? Modules themselves can't really do much "deal"ing; if they try to call functions that don't exist then they will just break. If there were a reliable fallback then that's what the module would (should) use in the first place. The only other kind of dealing I can think of involves module metadata and the puppet module tool, but it's not clear to me what kinds of problems you suppose module authors need to deal with in that area. > * How should we handle future, breaking changes? > * A function is corrected/modified and is thus not backwards > compatible (it is not deprecated, just changed behavior). > Alternative 1: don't do that; create a new function instead. This is a tried and true strategy. Alternative 2: continue applying semantic versioning to stdlib, and refer back to "How should module authors deal with their dependency on stdlib?" > * A function changes signature (it is called with a different set > of arguments). > See above. > * Should we have "backwards compatibility" as a separate module for > those that want to use older modules on a newer Puppet? (e.g. > stdlib-puppet3compat). > That would be a reasonable approach for functions removed from stdlib and not otherwise moved anywhere else. It would be sure to cause a tremendous mess if done for stdlib functions that were modified. > * Do we have to namespace functions (to allow multiple versions of the > same function for different modules?) > "Have to"? No. I think it's a good idea, however. > * Do we have to use a scheme such as adding a number after a > function/type > You mean when new behavior or signature is desired for an existing function? Yes, I think the best approach is my alternative 1, which is typically implemented by giving the new function a name derived from the old one's. > * Do we need to implement module specific loading (allow multiple > versions of a function). > I think namespacing functions is a better strategy. > * What about types and providers? Since they all have to co-exist in > the same catalog it is not really possible to support multiple > versions. How should we deal with types and providers? > > I think the only significant issue there that is not analogous to the situation with functions is third-party providers for existing types. That's a thorny issue that I'm not prepared to address at the moment. John -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/73ef8198-8f44-4ecc-bbd1-f8c53de34261%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
