-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reactors must support a "usage" command #8
Comments
Here's a worked example of what such a usage command might look like. We assume here that the reactors package supports multiple context and message schemas.
|
Should this also print the variables set in secrets.json while deploying the reactor? |
You are right, and those are implied by the Configuration section above. From within the container, we don't actually know variables are set by the secrets.json mechanism. We only know the universe of possible variable names, which are derived from the namespace ( |
Here's an example of the "Configuration" section of a live-generated
Comments are welcome |
Here is the latest draft of a
|
Thanks, Matt. What do you think about moving some (most) of this to online documentation? The idea is to remove all the content that does not change between different reactors, and refer users to the docs for details on how the SDK functions in general (and how they could develop their own reactors, extend/modify others' reactors).
The thought here is that the person running the
Thoughts? |
|
+1 on all three points here.
This is similar to what you have under Okay that's enough rambling for this comment 😉 |
After some prototyping, here's another go. I still have not implemented metadata, but I am able to generate a sensible run string for the case where there is 0-1 contexts and 0-1 message schemas. For environment variables, I use the Regarding Hypothesis: The
|
This looks great IMO. My only question is why the |
At this point, it's just an experiment to see which approach works the best, and I can probably converge them when I refactor. I wanted to get the live-generated example out for comment. |
Cool, I like the |
This looks great. I was able to understand the usage command output easily, especially the
|
Thanks for the feedback! For question 1: We're just printing the preferred schema to the screen. We are forced to assume a little bit of familiarity with reading and interpreting JSONschema on the part of the user. Note that we do generate an For question 2: Configuration for a database connection would probably be specified by the developer of the Reactor using
We don't have a good way to annotate the YAML configuration since PyYAML does not support comments. I think we just have to rely on well-named configuration keys in the Now that I look at it, we might want to explicitly point out that the |
Thanks a lot Matt. |
Part of the work to define context and schema validation is to make it possible to provide a minimally helpful
usage
command for a given Reactor that can be called directly from the Docker image:docker run -it <reactor-image> usage
.The text was updated successfully, but these errors were encountered: