On Wed, Jan 22, 2014 at 1:15 PM, Henrik Lindberg < [email protected]> 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. > I figured I'd have a stab at some answers to get the ball rolling. > * Is there content in stdlib that really belongs in core? > Well, the validation stuff does and is covered by your type system, moving forward. The stuff I would argue belongs in the core (and almost certainly redesigned from what's in stdlib) are: 1) Validation, which comes in with the type system. We have all the validate() and is_*() functions in stdlib. 2) Better ways to get information from other parts of puppet: things like getparam() in order to be able to reach into a define for a value, getvar(), get_module_path(), 3) Better ways to handle duplicate resources: We have ensure_packages, ensure_resources, all hacks to deal with duplication. 4) Iteration over certain data. We know future parser has iteration which solves most of this and the only other use cases are the has_*() functions which will mostly be replaced by structured data and iteration. These were the things where we've got multiple functions and so they feel like language issues to me. The rest is mostly genuine stdlib stuff. > * Is there content in stdlib that should never have been included (it > should really be in a different module)? > There's definitely been a tendency towards merge all the things. Maybe we need a more sophisticated breakup in terms of "broadly applicable" and "weird specific code", stdlib and stdlib-extras. We could maybe do a run through forge for usages of each thing to determine how frequently used they are to help that split. > * How do we keep stdlib in sync with the Puppet version? > My idea would have been major version stays in sync with major Puppet release but we kind of ruined that for ourselves. :D > * How should module authors deal with their dependency on stdlib? > * 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). > * A function changes signature (it is called with a different set > of arguments). > * 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). * Do we have to namespace functions (to allow multiple versions of the > same function for different modules?) > * Do we have to use a scheme such as adding a number after a > function/type > * Do we need to implement module specific loading (allow multiple > versions of a function). > There's a lot of questions here, and I'm struggling to find good answers to them. While reading this I had a gut instinct of: "Part of the problem is that stdlib is once again just a big ol' blob of stuff. Maybe stdlib should be a Modulefile that requires a whole bunch of smaller puppetlabs-stdlib-function modules of various versions. We roll them up into stdlib releases and test them against new versions of Puppet. If you need to correct a function then you can always just upgrade puppetlabs-stdlib-validate_bool or whatever." > * 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? > This needs to be deferred until we have isolated environments in Puppet and this is really something that needs to be a huge priority. We've run into it with PE, when we want to make pe_X versions of modules so that users can install a newer concat without messing with pe_concat but then we run into the issue of newer types and providers crashing into older ones. If anything I guess the heart of my replies is "Maybe stdlib needs to be a container for smaller modules." It's modules all the way down, people! -- 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/CAPfZVDah5X%3DbGKsmv8aucJK0rNn4EpuNweq9Hh6GnCB%2BtizyWA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
