Currently, according to the documentation, important configuration values are pulled from the environment at compile time in config.exs
If one attempts to also set these values in runtime.exs when the application starts up, the entire application will fail to start because the configuration was changed and the values are marked as compile time values.
This poses rather large inconveniences as the path to a database is an operational concern that is often handled by a deployment mechanism (such as docker compose or Kubernetes) rather than a build mechanism.
Also the environment needs to contain secrets to access Postgres, which poses a problem if the application is delivered as a Docker image since Docker images are generally not the place you want your secrets to be stored at - and in fact these values might not even be known at build time (for example if you give your application to other people for them to self host - you do not know their postgres credentials)
Expected Behaviour:
configuration can be (re-)defined in config/runtime.exs and set configurations such as :duckdb_path and :app_domain to values that differ from those in config/config.exs at compile time
Nota Bene:
I have not gotten around to testing if simply telling Erlang to ignore this issue would deploy successfully, but I don't think it's desirable in general to have to use that flag when starting your application as the same issue might occur with other pieces of code where the ignore flag would then shadow a real problem
Currently, according to the documentation, important configuration values are pulled from the environment at compile time in config.exs If one attempts to also set these values in runtime.exs when the application starts up, the entire application will fail to start because the configuration was changed and the values are marked as compile time values.
This poses rather large inconveniences as the path to a database is an operational concern that is often handled by a deployment mechanism (such as docker compose or Kubernetes) rather than a build mechanism. Also the environment needs to contain secrets to access Postgres, which poses a problem if the application is delivered as a Docker image since Docker images are generally not the place you want your secrets to be stored at - and in fact these values might not even be known at build time (for example if you give your application to other people for them to self host - you do not know their postgres credentials)
Expected Behaviour: configuration can be (re-)defined in config/runtime.exs and set configurations such as :duckdb_path and :app_domain to values that differ from those in config/config.exs at compile time
Nota Bene: I have not gotten around to testing if simply telling Erlang to ignore this issue would deploy successfully, but I don't think it's desirable in general to have to use that flag when starting your application as the same issue might occur with other pieces of code where the ignore flag would then shadow a real problem