Aha, ok, I had a quick look at those selectors and suspect it might be where things get dicey.
I assumed you were producing validators and extractors, possible integrators, and that you would let users of pyblish-deadline determine how their scene is organised. A selector, almost any selector, is bound to be very personal.
What I would suggest, is that instead of distributing selectors, write a contract.
The contract would specify the family for which Pyblish Deadline plug-ins - validators and extractors, - support along with any data the plug-ins require. In a nutshell, turn each of the selectors into contracts that studios can choose to implement themselves.
The Deadline Write Node Contract
For Deadline to validate your
Instance's, it must contain the following.
outputFileName0: # Absolute path to where a rendered sequence is to be written
deadlineFrames: # Dash-separated string of start and end frame, e.g. 1-10
EnforceRenderOrder: # Whether to enforce the order in which renders occur
NukeX: # Absolute path to Nuke X
Version: # Version of Nuke X
EnforceRenderOrder and others are fixed, I would suggest you strip these from the selector/contract and instead insert them implicitly right before anything is sent off to Deadline. The smaller the contract, the easier it is to get started, and also means less maintenance cost for both you and the user.
The contract should not only specify which members are necessary, but also optional, along with their effect on the end result. Additionally, every member must be defined in detail exactly how Pyblish Deadline expects it to be formatted, like in the case of
The less specific you require them to be, the better. There's a saying when it comes to designing Contracts/API's that you should be as tolerable as possible for any kinds of input, but only output the utmost critical and be as consistent as possible. I think that balance applies well here too. Let your users be liberal, but provide only predictable and rational outputs.