Context input type #30
Conversation
| 'value': { }, # Context inputs can have any type, or none at all | ||
| }, | ||
| 'required': [ 'base', 'found', 'value' ] | ||
| } |
There was a problem hiding this comment.
Is there a better place we can put this spec in the long run? I think it would improve readability.
There was a problem hiding this comment.
Yeah, I'm totally open to different approaches. Templating a JSON schema might be its own unreadable mess, but maybe these could eventually become separate JSON files that are loaded & modified?
| @@ -100,10 +100,10 @@ Note, the `// comments` shown below are not JSON syntax and cannot be included i | |||
| }, | |||
|
|
|||
| "description": "A set of 3D coordinates." | |||
| } | |||
| }, | |||
| // Not guaranteed to be found - the gear should decide if it can continue to run, or exit with an error. | ||
| "matlab_license_code": { | ||
| "base": "context", | ||
| }, |
There was a problem hiding this comment.
I actually leave those in intentionally, since the comments make it invalid JSON anyway (I have the code block set to js syntax), just so diffs can be cleaner. Maybe that's dumb.
| Context inputs are values that are generally provided by the environment, rather than the human or process running the gear. These are generally values that are incidentally required rather than directly a part of the algorithm - for example, a license key. | ||
|
|
||
| It is up to the gear executor to decide how (and if) context is provided. In the Flywheel system, the values can be provided by setting a `context.key-name` value on a container's metadata. For example, you could set `context.matlab_license_code: "AEX"` on the project, and then any gear running in that project with a context input called `matlab_license_code` would receive the value. | ||
|
|
There was a problem hiding this comment.
Did we resolve how the full context will be assembled in the flywheel system? (i.e. do we walk up the tree, taking values in the closest container to populate the context?) Maybe this isn't the place to expound on details of the Flywheel system, but since Flywheel was mentioned, can this link to documentation that has more detail?
There was a problem hiding this comment.
Yes, and yes once it exists respectively. I do want to keep a clean separation - not much point to a spec if it can't be implemented at least twice - and the FW contexts will be implemented after this merge, so let's update with a link to docs.fw in a future PR.
Provides typeless, no-guarantee contextual key/value pairs on demand.
Also took the opportunity to clean up the generator a bit and add output to
validate.py.Closes #26. Merges after #28, see versioning notes there.