Can't change config without doing a `mix deps.clean fun_with_flags`.

[tompave]

Can't change config without doing a `mix deps.clean fun_with_flags`.

[jeremyowensboggs]

Just thinking through some possible approaches (only half baked ideas)

1. Do nothing, document, and maybe even switch persistence_adapter and notifications_adapter to compile time as well.
2. Switch to run time config for cache, like persistence_adapter and notifications_adapter currently use.

Bigger changes/interface breaking

3. Attempt some kind of macro magic so that the actual compilation happens in the app, similar to ecto.

defmodule MyApp.FunWithFlags do
  use FunWithFlags,
    cache: true

  # Generates FunWithFlags interface with either the FunWithFlags.Store or
  # FunWithFlags.SimpleStore module
end

4. Provide either a FunWithFlagsCache module, or <action_name>_cache functions to access the cache, so instead of an config option for using the cache, the developer instead determines based on how they call the flags function?

Thanks for the library and the work you do.

[tompave]

Hello, thank you for using the library and for opening the issue.

As far as I can see, that warning is working exactly as intended.
Running mix deps.clean fun_with_flags before your CI runs seems the right way to go. I get it's annoying, but I wonder why it is necessary in the first place. Are you running CI several times with different FWF configs?

On the suggestions on your second message:
1a. There was a Readme section to describe compile-time config issue, but I removed it when I adopted Application.compile_env/3. The idea was that the warning you get is enough to explain what's happening and what to do, and based on your comment I think that it's working as expected.
1b. I wouldn't switch the persistence and notification adapters to compile-time config. Compile-time config is annoying and I'm using it for the cache only for performance reasons, because those config values are checked often in the read hot path, and I don't want an extra ETS lookup and function calls there. On the other hand the persistence and notification adapters are only used when writing, therefore traditional config management is fine there.
2. See previous point.
3. I actually have an old branch where I'm working towards that kind of API. It's something for version 2.0 though.
4. I see what you mean, but I'd rather not do that. A design goal of FWF is to have a very simple API, and I don't think users should have to decide whether to go through the cache or not every time they check a flag. That's asking for trouble, because code that is "fast enough" without cache today can become painfully slow (and cause an incident) tomorrow if something else changes.

[jeremyowensboggs]

Hi, thank you for the prompt reply. I'll expand on the issue we are seeing just for clarity. The issue with CI is that is that things are cached from the previous build. When I first introduced fun_with_flags, the build would not complete due to this error. Since the build is automated, the only way to fix it is to do another commit with the instruction to do a mix deps.clean fun_with_flags. Looking over our docker setup, there may be additional things we can do there....

Thank you for the explanations. I'll close this issue.