Hi, In general, I'd rather see a different switch such as `-e` for setting environment variables as I'm suspicious of a `param` having different meanings which risks confusion.
Regards, Rob > On 27 Jun 2019, at 01:21, Tyson Norris <tnor...@adobe.com.INVALID> wrote: > > 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 > > > > -- Development thoughts at http://akrabat.com Daily Jotter for macOS at http://dailyjotter.com
