keep module.run

[cmcmarrow]

Salt had decided to keep module.run. This is because the replacement function is missing features and has a sharper learning curve.

[OrangeDog]

What does this mean exactly? You mean the old syntax for a module.run state is no longer deprecated and will never be removed?
What effect does this have on e.g. #57919?

[cmcmarrow]

@OrangeDog right now we are planing for keeping the old syntax for module.run. There is no plan on removing the old syntax. I don’t believe this should effect #57919.

[OrangeDog]

Well it certainly removes the easy solution - remove both the deprecated syntax and the config option.

[max-arnold]

@cmcmarrow Could you please clarify the missing features part? What exactly is missing from the new module.run implementation?

[OrangeDog]

I'm also a bit confused, because the new syntax allows for more expression, not less, and should be easier to learn because it's closer to the general state syntax.

[sagetherage]

I brought this up with the Core team and the new module.run is complex, but in use, it does make it easier to write states, but the learning curve is steep. The team wanted to properly deprecate the new module.run in a year since this would break states. I can't really say more as that is all I know, but I have asked @dwoz to chime in, here to answer your question @OrangeDog regarding syntax.

[dwoz]

We, the core team, including myself had a conversation about this and we did come to a consensus to not deprecate the old way. The reasoning for not wanting to deprecate the old way is that people are extremely sensitive to changes which cause existing state trees to break. Breaking changes like this can prevent people from upgrading to newer versions of Salt and we want people to move forward.

Having said that, I also think we need to listen to the community. I would like to think there are ways we can move forward and make significant improvements when it makes sense. After digging into this change a bit more, I am on the fence on this one. On one hand the syntax introduced by this change is clearly cleaner and more intuitive. I do not think anyone will argue that point. On the other hand, the change is mainly just syntactical. The only significant feature that I see added by the new syntax is the ability to pass *args to the function being called. I should be clear that I am not a fan of module functions accepting *args and/or **kwargs. My opinion is that does not warrant a breaking change. So for me, the question comes down to whether or not having cleaner and more intuitive syntax warrants the breaking change.

[max-arnold]

What about gradually phasing out the old syntax?

[OrangeDog]

I'd argue that going through a full deprecation cycle relying on a misnamed config option, delaying it (it used to say it would be removed in Sodium), and then reversing it is a lot more disruptive. You can't go back to just the old version, because then the problems for which it was replaced come back again. If you really want to keep it for some reason, then just change the code to handle both syntaxes without needing a config change, or at minimum make the new syntax the default.

This is also confusing as the previous messaging was you were expecting to making breaking changes every major release. So why is this already almost already complete change suddenly a problem?

[OrangeDog]

Resolved by #61772