Library Structure

[thdxr]

Goth is structured so it reads configuration at start and then attempts to verify credentials. This makes it very difficult for it to work in environments where configuration is loaded dynamically. Take a look at this article for best practices to avoid this issue and other cascading ones: https://michal.muskala.eu/2017/07/30/configuring-elixir-libraries.html

I need to be able to disable all Goth functionality for local development and use it only in production. There's really no clean way to do this in Goth currently

[thdxr]

Looks like there's a PR that addresses this already: https://github.com/peburrows/goth/pull/45

[peburrows]

There are actually already two clean ways to do this:

1. You could explicitly disable Goth in your dev config via config :goth, disabled: true
2. You could load the config dynamically via the built-in callback. Look at https://github.com/peburrows/goth/pull/32 for more info

[peburrows]

By the way, that’s not to say that #45 wouldn’t also be helpful, but I don’t believe it’s a requirement for the scenario you described.

[thdxr]

Explicitly disabling goth via config means the only way I can enable it is changing the config at release time. Still prevents me from selectively disabling goth at runtime in certain environments

I'm not certain on this but I think the callback module still gets called before my application starts up so it doesn't work for runtime configuration that is initialized in my application.

The recommendation for library authors section details a few options that provide a path forward without these limitations.

[peburrows]

Explicitly disabling goth via config means the only way I can enable it is changing the config at release time. Still prevents me from selectively disabling goth at runtime in certain environments

There's no need to change your config at release time. Instead, it's easily accomplished with different configs for different environments, which is very common practice. Phoenix applications, for instance, are generated by default with per-env configs.

The recommendation for library authors section details a few options that provide a path forward without these limitations.

The very article you link to suggests a callback module for stateful libraries, which is exactly what Goth does.

I'm not entirely sure what it is you're wanting to be changed, but I'll be happy to review a PR that addresses the limitations you're running up against.