Issue #1478 Avoid validate_legacy deprecation failure on Puppet 8#1479
Issue #1478 Avoid validate_legacy deprecation failure on Puppet 8#1479alex-harvey-z3q wants to merge 2 commits into
Conversation
…ppet 8 Do not call the deprecated stdlib deprecation function from validate_legacy. Under Puppet 8 strict settings this can raise before validate_legacy evaluates the supplied value, which breaks modules that still call validate_legacy.
|
|
|
@CLAassistant Note that I changed my GitHub handle from alexharv074 to alex-harvey-z3q which could explain why it shows me as having not accepted the CLA. I've accepted again. |
|
The failing build does not appear related to my PR. |
|
@alex-harvey-z3q : Thanks for putting in this PR. If I'm reading your request correctly, you have a scenario where you are running on strict mode so the deprecation on validate_legacy is causing a full error on other modules. Have you identified which module(s) in your dependency tree are still calling validate_legacy (or the older validate_* functions) directly? If it's something you maintain, updating those modules seems like the more durable fix than patching stdlib's runtime behavior. If it's a third-party module you don't control, perhaps we can get PRs in on those modules to fix their use of a deprecated function.
|
Pass false for the strict-setting flag when validate_legacy calls the stdlib deprecation helper. This preserves the deprecation warning for module maintainers, while preventing Puppet strict mode from turning the warning into a hard failure before validation runs.
|
@jst-cyr Yes I see your point. How is this updated version of the PR that keeps the E.g. lib/puppet/functions/validate_legacy.rb (line 55) I will also trace the dependency tree that is still calling |
|
Given these functions where deprecated in 9.0.0, I would have expected them to be removed in 10.0.0 (but they have not). I really do not think that making them less "harmful" is a move in the right direction. |
I have different expectations because this is enterprise software. I would expect enterprise software not to have bugs in it, and I would expect the maintainers of enterprise software to understand that enterprises move slowly. |
By removing the function, you make it harder for people to upgrade to newer stdlib. |
cvquesty
left a comment
cvquesty
left a comment
There was a problem hiding this comment.
I'm with Alex fisher... we do need to make attempts to keep the barrier lower and the file changes nominal if we can. I think it's important to realize, as mentioned, that we're all volunteers but at the same time this project exists because the puppet folks couldn't keep momentum nor get to the really necessary updates and changes in a timely fashion largely due to blast radius, being overwhelmed when there are indeed several changes that need to happen, thus they did nothing (or next to it...or moved painfully slow)
The conversation around appropriateness for a purpose is important, though. we can't prefer one over the other, and have to strike a medium balance here in that yes, we need to see these as enterprise software but at the same time, there is a mechanism to duplicate and expand on forge modules that are poor or not meeting one's needs. The validate functions have been gone for quite some time now (3 years), but this represents 10 releases. I think they can safely be let go now.
6 participants
Summary
Remove the direct
deprecation()call fromvalidate_legacy()so otherwise valid catalogs do not fail under Puppet 8 strict deprecation handling before the function performs its type assertion.validate_legacy()remains deprecated as an API, but this change preserves its compatibility behavior for modules that still depend on it while they migrate to native Puppet data types.This also updates the
validate_legacyfunction specs to assert that the function no longer invokes the stdlibdeprecationhelper in its existing pass/fail cases.Checklist