For the incremental change I would suggest:
- include the action-configured params as args to init
- optionally: include an invoker flag to optionally remove action-configured
params from being sent to run (these would only be available by way of init
setting env vars, or exposing some other object)
- runtimes can be updated incrementally to support this flagged invoker behavior
I understand the point on amount of work, I'm just not wanting to sacrifice an
awkward behavior (different treatment for params in upper case) for sake of
time. There are some accumulating issues around init and run so I'm not sure it
is worth making the problem worse before addressing the other issues. I think
its ok to change init to receive these params as a minimal change, but
obviously without additional changes either at invoker or in OW's convention
for designing functions (main sig, how to access init vars, context) there will
be some incremental pain as well.
Still curious what others think.
On 6/26/19, 11:27 AM, "Rodric Rabbah" <rod...@gmail.com> wrote:
> Sorry, it still seems controversial to me, not sure how others feel?
That's why we discuss on the dev list :D Thanks for the feedback so far.
> can you confirm this is decided based on the case of the parameter name?
Indeed, we need some rule to then partition the parameter list. Using the
convention that the env var starts with a capital letter is one. Other
conventions are plausible.
> adding a '-e' flag that specifically does "set these environment
variables"
Sure - but this increases the complexity of implementation significantly
for not a lot of gain. To add a -e, we'd need to modify the schema for
actions. For example, we could add annotation for each parameter name to be
treated as an environment variable using the existing annotations, and use
these annotations as the criteria. We could create a new field in the
actions object to hold the parameters (a schema change). We could annotate
each parameter (also a schema change).
Since a developer already controls the names of their parameters today,
they have complete control over this partitioning.
If we're open to schema changes, then we can explore a cleaner
implementation but an incremental approach that at least makes the feature
available incrementally would also make sense since making a schema change
is a lot more invasive, coupled with a few changes needed at the invoker
level plus all the runtimes.
-r
