I am inclined to be more explicit. Whenever users forget about the difference between uppercase and lowercase parameters, the feature may not work as they expected. So I am inclined to Tyson's opinion to explicitly add another flag such as "-e".
If it could be overhead to change the schema, how about relying on annotation? I think it makes sense to set environment variables at action creation time. We can introduce a new annotation to set environment variables, or apply some rules against the existing flag "-a" as Rabbah suggested. Best regards Dominic 2019년 6월 27일 (목) 오전 8:52, Rodric Rabbah <rod...@gmail.com>님이 작성: > The use of env vars wouldn't be an issue with intra-container concurrency > if they're immutable, right? The more specific issue that arises today > which I think is your primary concern, are the __OW_ system provided > environment variables which mutate with each invocation of main. Is that > right? > > If so, then I think there are only two issues: > 1. do we introduce a context object (did you see my other dev list mail?) > 2. logging > > i really think my issue is orthogonal to these concerns - it's a > convenience feature for the developer. An action can already export > environment variables today from main. > > -r > > On Wed, Jun 26, 2019 at 8:44 PM Tyson Norris <tnor...@adobe.com.invalid> > wrote: > > > Sorry, what I meant was: accumulating issues around the "main" function, > > which are: > > - context > > - use of env vars > > - your issue: separating user provided params from developer-provided > > params > > - completely separate, but worth noting: logging (and env vars) in the > > face of concurrency > > > > On 6/26/19, 5:29 PM, "Rodric Rabbah" <rod...@gmail.com> wrote: > > > > > There are some accumulating issues around init and run. > > > > Which issues are these? > > > > -r > > > > > > >
