In this case it wouldn't help to change Application.get_env because the plug function you are using it doesn't actually call that function. I am afraid you would still have to patch every plug library using this kind of configuration.
On Thu, Mar 2, 2017 at 2: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 >> > 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/ms >> gid/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 > <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. > -- Eric Meadows-Jönsson -- 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/CAM_eapjHHQdQcQ57%2BKwGM-wO6NaDxALd9SAw2i3kwy1rLruR4Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
