Good idea to split the discussion. We can complete PipelineOptions.fromSystemProperties immediately for Java and separate the cross-language "multi-env var representation" for pipeline options. Probably Python & Go fans have muted this thread, after all.
On Fri, Feb 16, 2018 at 8:07 AM, Romain Manni-Bucau <[email protected]> wrote: > Oh, so the point was than env would be under the portability umbrella > versus system properties are not? Kind of makes sense phrased this way for > me. > > Do we want another thread for that? > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > 2018-02-16 16:37 GMT+01:00 Kenneth Knowles <[email protected]>: > >> >> On Thu, Feb 15, 2018, 11:47 PM Romain Manni-Bucau <[email protected]> >>> wrote: >>> >>>> >>>> 2018-02-15 20:00 GMT+01:00 Kenneth Knowles <[email protected]>: >>>> >>>>> On Thu, Feb 15, 2018 at 12:03 AM, Romain Manni-Bucau < >>>>> [email protected]> wrote: >>>>>> >>>>>> 2. default properties = env + system properties: this is what all >>>>>> config libs do (spring config, tamaya, deltaspike, microprofile-config, >>>>>> ...) so it is very comfortable and sane for end users. It enables ops >>>>>> (env) >>>>>> and dev (system properties) to feel comfortable for free with this and >>>>>> avoids us to have N entry points which has the nice side effect to >>>>>> consolidate the overall consistency of the framework/lib. >>>>>> >>>>> >>>>> Can you link to the docs for these examples? I'm sure we'd like to >>>>> learn from them. >>>>> >>>> >>>> I'm not the best to find docs but the relevant bits are: >>>> >>>> https://github.com/apache/deltaspike/blob/842c84bd1767905a19 >>>> e2af01bdfe88d416d1b2da/deltaspike/core/impl/src/main/java/ >>>> org/apache/deltaspike/core/impl/config/DefaultConfigSourc >>>> eProvider.java#L57 >>>> https://github.com/apache/geronimo-config/blob/trunk/impl/sr >>>> c/main/java/org/apache/geronimo/config/DefaultConfigBuilder.java#L182 >>>> https://github.com/spring-projects/spring-framework/blob/a0b >>>> ce618c2f51d8af1fc00ee2c3868ba2c8e0045/spring-core/src/main/j >>>> ava/org/springframework/core/env/StandardEnvironment.java#L78 >>>> >>>> (and there are others a bit less mainstream) >>>> >>>> The point is just that it is very common to read both and would be >>>> weird to not have that feature if we read from system props. >>>> >>> >> I'm convinced that it is common. It isn't clear that it is useful. But >> since it has very little impact I'm fine with it. We can take the Java >> naming problem to the PR. >> >> Now the schema for this collection of env vars is a cross-language >> question, so we need to make sure Python and Go are on board. >> >> Kenn >> > >
