Re: [elixir-core:6979] Application.get_env/2 support for {:system, "VARIABLE"}

2017-03-01 Thread Almas Sapargali
You can take a look at https://github.com/bitwalker/conform 
, it’s like config.exs, but captures env 
variables during application start, unlike config.exs which captures during 
compilation.


> On Mar 2, 2017, at 7:26 AM, Christian Nelson  wrote:
> 
> The version of this issue I ran into today is with a 3rd party plug, 
> https://github.com/remiprev/plug_canonical_host. I wanted to do something 
> like this:
> 
> defmodule HalfDome.Endpoint do
>   use Phoenix.Endpoint, otp_app: :half_dome
> 
>   plug PlugCanonicalHost, canonical_host: System.get_env("CANONICAL_HOST")
> 
>   #...
> end
> 
> But, between the compilation of the file and the "plug" macro expansion, 
> System.get_env("CANONICAL_HOST") is resolved at compile time. I'm pretty new 
> to Elixir and I tried 4-5 things to have the lookup be dynamic without any 
> luck.
> 
> So, I submitted a pull request to that library 
>  so that it supports 
> the {:system, "CANONICAL_HOST"} syntax. It was easy to do and works. 
> Unfortunately we have other situations where we want to do the same thing and 
> it's not easy to patch every library that's out there.
> 
> Also, I noticed that in the phoenix code, many instances of {:system, 
> env_var} are flagged for deprecation in 1.4... which makes me think trying to 
> perpetuate this convention could be a bad idea.
> 
> Is there some elixir-fu that would make it easy(ish) to fetch the 
> CANONICAL_HOST at runtime in the example above?
> 
> Thanks!
> Christian
> 
> On Wednesday, March 1, 2017 at 9:26:01 AM UTC-8, Almas Sapargali wrote:
> Hello, I'd vote for this change too, actually found that and other 
> discussion, when I was going to make exact same proposal, and just did a 
> quick search first. Then only notable stopper I've seen is that values would 
> be strong, whilist user may expect int/bool etc. I think we could handle this 
> case by passing some typing info in first element, like {:system_int, 
> "POOL_SIZE"} etc, which would evaluate to nil if env isn't set or not an 
> integer. 
> 
> 
> On Saturday, December 17, 2016 at 3:17:35 PM UTC+6, José Valim wrote: 
> > There has been a couple discussions on the topic either here or on the 
> > issues tracker. 
> > 
> > 
> > The consensus is that this problem needs to be solved but we are not quite 
> > sure how. The only way to support {:system, "DATABASE_URL"} in a way that 
> > it would also work for Erlang applications is by hijacking the application 
> > controller using private APIs. We could also try solve this exclusively for 
> > Elixir but then there would be gaps where it wouldn't be supported. 
> > 
> > 
> > Ecto 2.1 is trying a new approach where the value is configured using a 
> > repository callback, that's what we will try to do when Phoenix 1.3 comes 
> > out and see where it will lead us to. 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > José Valim 
> > 
> > www.plataformatec.com.br  
> > Skype: jv.ptec 
> > Founder and Director of R 
> > 
> > 
> > On Sat, Dec 17, 2016 at 1:48 AM, Cory ODaniel > 
> > wrote: 
> > 
> > I've definitely run into issues where I need to pass an environment 
> > variable at run time, but an application that I use doesn't support the 
> > {:system, "DATABASE_URL"} or {:system, "PORT"} style environment variables 
> > that Ecto and Phoenix support. 
> > 
> > 
> > I'm curious if it would be beneficial to add support in 
> > Application.get_env/2 that when the value that returns matches {:system, 
> > var} then System.get_env(var) would be called under the hood. 
> > 
> > 
> > 
> > 
> > 
> > 
> > -- 
> > 
> > You received this message because you are subscribed to the Google Groups 
> > "elixir-lang-core" group. 
> > 
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to elixir-lang-co...@googlegroups.com <>. 
> > 
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/elixir-lang-core/9fd6e998-04d2-4d7d-87ee-34abb16ee779%40googlegroups.com
> >  
> > .
> >  
> > 
> > For more options, visit https://groups.google.com/d/optout 
> > . 
> 
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "elixir-lang-core" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/elixir-lang-core/GwR7b9OVRcc/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> elixir-lang-core+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> 

Re: [elixir-core:6979] Application.get_env/2 support for {:system, "VARIABLE"}

2017-03-01 Thread Christian Nelson
The version of this issue I ran into today is with a 3rd party 
plug, https://github.com/remiprev/plug_canonical_host. I wanted to do 
something like this:

defmodule HalfDome.Endpoint do
  use Phoenix.Endpoint, otp_app: :half_dome

  plug PlugCanonicalHost, canonical_host: System.get_env("CANONICAL_HOST")

  #...
end

But, between the compilation of the file and the "plug" macro expansion, 
System.get_env("CANONICAL_HOST") is resolved at compile time. I'm pretty 
new to Elixir and I tried 4-5 things to have the lookup be dynamic without 
any luck.

So, I submitted a pull request to that library 
 so that it 
supports the {:system, "CANONICAL_HOST"} syntax. It was easy to do and 
works. Unfortunately we have other situations where we want to do the same 
thing and it's not easy to patch every library that's out there.

Also, I noticed that in the phoenix code, many instances of {:system, 
env_var} are flagged for deprecation in 1.4... which makes me think trying 
to perpetuate this convention could be a bad idea.

Is there some elixir-fu that would make it easy(ish) to fetch the 
CANONICAL_HOST at runtime in the example above?

Thanks!
Christian

On Wednesday, March 1, 2017 at 9:26:01 AM UTC-8, Almas Sapargali wrote:
>
> Hello, I'd vote for this change too, actually found that and other 
> discussion, when I was going to make exact same proposal, and just did a 
> quick search first. Then only notable stopper I've seen is that values 
> would be strong, whilist user may expect int/bool etc. I think we could 
> handle this case by passing some typing info in first element, like 
> {:system_int, "POOL_SIZE"} etc, which would evaluate to nil if env isn't 
> set or not an integer. 
>
>
> On Saturday, December 17, 2016 at 3:17:35 PM UTC+6, José Valim wrote: 
> > There has been a couple discussions on the topic either here or on the 
> issues tracker. 
> > 
> > 
> > The consensus is that this problem needs to be solved but we are not 
> quite sure how. The only way to support {:system, "DATABASE_URL"} in a way 
> that it would also work for Erlang applications is by hijacking the 
> application controller using private APIs. We could also try solve this 
> exclusively for Elixir but then there would be gaps where it wouldn't be 
> supported. 
> > 
> > 
> > Ecto 2.1 is trying a new approach where the value is configured using a 
> repository callback, that's what we will try to do when Phoenix 1.3 comes 
> out and see where it will lead us to. 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > José Valim 
> > 
> > www.plataformatec.com.br 
> > Skype: jv.ptec 
> > Founder and Director of R 
> > 
> > 
> > On Sat, Dec 17, 2016 at 1:48 AM, Cory ODaniel  
> wrote: 
> > 
> > I've definitely run into issues where I need to pass an environment 
> variable at run time, but an application that I use doesn't support the 
> {:system, "DATABASE_URL"} or {:system, "PORT"} style environment variables 
> that Ecto and Phoenix support. 
> > 
> > 
> > I'm curious if it would be beneficial to add support in 
> Application.get_env/2 that when the value that returns matches {:system, 
> var} then System.get_env(var) would be called under the hood. 
> > 
> > 
> > 
> > 
> > 
> > 
> > -- 
> > 
> > You received this message because you are subscribed to the Google 
> Groups "elixir-lang-core" group. 
> > 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to elixir-lang-co...@googlegroups.com. 
> > 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/elixir-lang-core/9fd6e998-04d2-4d7d-87ee-34abb16ee779%40googlegroups.com.
>  
>
> > 
> > For more options, visit https://groups.google.com/d/optout. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/964e79d1-2b4f-4bc4-ae75-55c18ed42538%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.