Hi, thank you for voicing your feedback. I can't do my work without it.
On Thursday, October 20, 2016 at 10:49:45 AM UTC-7, asch...@redhat.com wrote: > > So I've recently noticed the deprecation notices for the validate_* and > is_* functions withing stdlib. As a consumer of the stdlib who currently > needs to continue to support puppet 3 and hasn't moved to puppet 4 typing > for ~40 modules, this is a giant pain. > If you are not yet prepared to make the switch, please stay with stdlib 4.12. > Additionally we do not require (nor leverage) any of the old edge cases > that are trying to continue to be maintained under the validate_legacy > function. > validate_legacy and the Compat types are not supposed to continue to maintain the mess that were the validate_ functions. They are designed to help you migrade in an incremental fashin, to leverage the new datatypes, without forcing your complete installation to switch ot once into the new world. If you have that kind of control over your modules, or you already know that you're hitting none of the edge cases, you can of course choose to do the switch in a single step. > Is there a reason we can't just keep these is_* and validate_* functions > as is without the deprecation and/or just fix these in a newer version of > stdlib? > You can. Stay with stdlib 4.12. > Is there some additional info as to why this decision was made? > We want to start using the "new" puppet 4 features in the supported modules to show off the improvements you can gain through them. The deprecation and validate_legacy functions are intended to help the whole ecosystem make this transition without having a flag day where everyone has to switch. Using datatypes has a number of advantages over the validate functions: * high expressivity: look through the Compat types to see what the functions *actually* tested. They accept surprising types and leak weird edge cases. Using datatypes removes a huge trap, and allows much stricter specifications. * documentability: puppet-strings will surface datatypes in the generated HTML. validate method calls are invisible. * core features: you can leverage the expressivity of datatypes using the =~ match operator and assert_type everywhere you previously used validate and is functoins, and the results have a much better chance of meeting everyone's expectations * extensiiblity: it is very easy to define custom types that match a module's domain, while it is very obscure to create your own validate functions. > Having to go through our modules and switch out to the validate_legacy > functions is an effort we don't have the resources to undertake and the > deprecation notices aren't something we can live with as they make it very > hard to figure out when something actually breaks. > Please see the documentation for the deprecation function in the stdlib readme on how to turn on/off deprecations in different situations (via puppet configuration on your master, or a environment variable during testing). You always have the possibility to stay on stdlib 4.12 until you are ready to start your upgrade project. > Additionally I'd like to point out that the deprecation notices make it > next to impossible to figure out what is deprecated, see > http://logs.openstack.org/89/388589/1/gate/gate-puppet-openstack-integration-4-scenario001-tempest-centos-7/fc2567b/console.html#_2016-10-19_22_24_59_667975 > > Crap. I missed that one. I'm currently at puppetconf, and travelling home afterwards, so I won't be able to look into it immediately, but I've created https://tickets.puppetlabs.com/browse/MODULES-3993 to track this, and will get to it next week. Until then, grepping for 'validate_|is_' is probably a good first approximation of everything you'll need to address. Cheers, David -- 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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/25f0f2a9-c3e1-49f1-9f7e-1f2e729425c3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
