Very closely related to this, I've found myself multiple times lately
wanting to write code that differed between development/test and
production; mostly to introduce some function-call checks in the
development-like environments that would not be there in production to
improve speed.
This is currently impossible to do without either:
- Depending on `Mix.env` existing, which breaks the library for anyone who
wants to build a release.
- Requiring manual configuration by the user of the library for each of the
environments.
I feel like cases like this are common enough to warrant the
standardization of a way to check the current execution environment.
On Monday, December 17, 2018 at 11:49:39 AM UTC+1, boris kotov wrote:
>
> Hi all,
>
> when dealing with umbrella applications, you may need for some of the apps
> special env, for example a "e2e_test.exs" which is relevant for the web
> app, but not for all apps within the umbrella.
> In my case, I've an subapp, which has a special configuration for the
> "test" env. But because I had to uncomment import_config "#{Mix.env()}.exs"
> line, I also have to provide all the other possible config files for all
> possible env within my umbrella. I ended up by providing empty config
> files, to make it not fail.
>
> Proposal:
>
> import_config should not fail if config cannot be discovered, or provide
> an optional-flag, like `import_config("#{Mix.env()}.exs", optional: true)`
> so the config directory will stay clean only with configs you need for that
> particular application.
>
> Thanks!
>
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/b7d2c952-0808-4f36-b1d2-514c3ad37261%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
