Thanks Austin, this is quite comprehensive, but way beyond the scope of
what I am proposing, which is to handle the two most common cases. For
anything sufficiently complex, this should be the responsibility of the
application/library.
On Tuesday, February 18, 2025 at 3:18:00 PM UTC-5 halos...@
I also posted about it on Elixir Forum:
https://elixirforum.com/t/enviable-robust-environment-variable-conversion/69360
On Tue, Feb 18, 2025 at 3:16 PM Austin Ziegler wrote:
> I recently moved to a new position where we use Dotenvy and
> `System.get_env!` etc. I developed
> https://hexdocs.pm/en
I recently moved to a new position where we use Dotenvy and
`System.get_env!` etc. I developed https://hexdocs.pm/enviable/Enviable.html
on my own time and have released it. It's fairly comprehensive—and by
fairly I mean extremely—and if there's something missing, I'm open to both
requests and pull
In Elixir applications, config/runtime.exs is often used to parse
environment variables from System.get_env2/ and friends, and convert into
Application configuration.
Since environment variables can only be strings, it is often necessary to
cast from string values into booleans and integer valu
FWIW in config/runtime.exs we can use dependencies and if we happen to have
Ecto we can use:
config :my_app, :bool_value, Ecto.Type.cast!(:boolean, System.get_env(“”,
“false”))
config :my_app, :maybe_int_value, (n = System.get_env("N")) &&
Ecto.Type.cast!(:integer, n)
What I like about
Hm…that makes sense. I’d maintain that it should end in a `!` for clarity
though, even if there is no non-raising variant.
> On Feb 18, 2025, at 11:28 AM, dave.lu...@gmail.com
> wrote:
>
> > I think a simpler alternative to an `as` option might be:
>
> > `System.get_boolean_env/1` and `System
> I think a simpler alternative to an `as` option might be:
> `System.get_boolean_env/1` and `System.get_integer_env/1` that return
things like:
> `{:invalid, value}` when the value can’t be parsed, but provide !
versions that raise errors, i.e
I do aree with type specific functions, but I don
I think a simpler alternative to an `as` option might be:
`System.get_boolean_env/1` and `System.get_integer_env/1` that return things
like:
`{:invalid, value}` when the value can’t be parsed, but provide ! versions that
raise errors, i.e
```elixir
config :something, port: System.get_integer_e
This would be quite helpful to deal with environment variables that are
expected to be boolean or integers. In my experience, I always have to
copy-paste a helper function to do the type cast:
defp to_boolean(nil), do: false
defp to_boolean(var) when is_boolean(var) do
var
end
defp to_bo
A solution to edge case values could be to allow the user to specify the
truthy values, e.g.
config :my_app, :bool_value, System.get_env_as!("BOOL_VALUE", "false", as:
:boolean, truthy_values: ["on", "true", "TRUE", "FIRE ME UP"])
I could also see separate functions for booleans and integers, b
The Gleam folks are working in a command to export the gleam.toml file as
JSON so we don't need to use regexes for this integration.
I have a question regarding the gleam javascript target. Can we support
that somehow?
I think that being able to use packages meant for the frontend in something
11 matches
Mail list logo
