You can take a look at https://github.com/bitwalker/conform <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 <christ...@carbonfive.com> 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 > <https://github.com/remiprev/plug_canonical_host/pull/7> 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 <http://www.plataformatec.com.br/> > > Skype: jv.ptec > > Founder and Director of R&D > > > > > > On Sat, Dec 17, 2016 at 1:48 AM, Cory ODaniel <co...@coryodaniel.com <>> > > 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 > > > > <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 > > <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 > <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 > <mailto: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 > > <https://groups.google.com/d/msgid/elixir-lang-core/964e79d1-2b4f-4bc4-ae75-55c18ed42538%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <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/0AFE8D64-955F-497D-AD0D-373088774896%40gmail.com. For more options, visit https://groups.google.com/d/optout.
