Stricter Signature Contract Enforcement in POP 27

Hey devs, POP 27 is making its entrance with a significant behavioral tweak around function signature contracts. This isn't the end of the world, but it does warrant some due diligence on your part. This blog post aims to give you a heads-up on what to expect and why you should care.

The Change

Previously, you could be a bit loose with how you implement function signatures in your plugins. POP 27, however, is less forgiving. If a contract specifies a parameter as positional, your plugin must also treat it as positional. No more mixing and matching; the terms of the contract are now set in stone.

The Wrong Way

Suppose you had this in your plugin:

# Signature Contractdef 
sig_foo(hub, a, b):
    pass

# Plugin Function - BAD
def foo(hub, a, b="default"):
    pass

Don't do this. It's a developer faux pas that needs correction. The "sig" contract said that "a" and "b" are positional parameters so they need to remain positional parameters in the plugin implementation.

ContractSigException: What It Means

If you're still mixing older idem versions (23 and below) with POP 27 and above, you might run into this:

pop.exc.ContractSigException: Signature Errors in /home/akmod/PycharmProjects/idem/idem/idem/resolve/iorder.py:
apply: Parameter "is_params" cannot have a default value

This isn't an app-breaker; it's a developer issue. You may have a couple files where you need to delete the default value of a parameter that the contract says is positional only.

The Right Way

Just stick to the contract, and you're golden:

# Signature Contract
def sig_foo(hub, a, b):
    pass

# Plugin Function - GOOD
def foo(hub, a, b):
    return a + b

The Takeaway

If you're an idem plugin developer, take some time to test your work against POP 27. This isn't a catastrophe waiting to happen; it's more like quality control on a granular level.

Conclusion

The stricter signature rules in POP 27 aren't arbitrary; they serve a specific purpose. Contracts in POP enforce predictable interfaces for a function. If a contract says that a parameter is positional, then any function adhering to that contract can be reliably called with a positional parameter. This fosters a more predictable, robust ecosystem for plugins, which is what we're all striving for. Also, let's not overlook flexibility. Sometimes, you may find yourself needing to add a default value to the sig contract. Why? Because you want that variable to offer some wiggle room. The changes in POP 27 accommodate that need while ensuring that the integrity and predictability of the function signatures are upheld.

So, keep your production python packages pinned in production, test with POP 27, and you'll navigate this update just fine. It's all about evolving while keeping things tight and predictable