Clojurians Log v2
beginners
Hi I need to set a variable so that code in production runs a different logic. Should i use https://github.com/weavejester/environ ? is it popular approach today ? I tired to use it. getting this: Error: cannot resolve environ.leiningen.hooks/activate hook Project setup: Trying to create a jpackage build of cljfx project.
No clue about that library, but if you need to only have a boolean condition that's checked at run time, I'd just the simplest (System/getenv "...").
so this variable controls dynamic loading of dev dependencies which i don't want in production. So i can write the logic to assume if the variable is not present its production environment. But then starting the application in dev will become a pain. I was looking for some application.properties like approach where prod has its own config file and dev has its own config. You run simple dev command and everything gets loaded from config.
depending on how complex it is, you may be able to just use deps.edn for this. look up the documentation for aliases: https://clojure.org/reference/deps_edn
the workflow would be something like:
1. define a :dev or :build alias with your dev dependencies
2. set a JVM property that indicates the alias is enabled with :jvm-opts ["-Ddev.enabled=true"]
3. Use (= "true" (System/getProperty "dev.enabled")) as a feature flag in your app like @p-himik suggested
I'm not super familiar with jpackage but https://clojure.org/guides/tools_build may also be worth looking into if you need to to use code to define the build logic.
i am using leiningen will explore this java opts trick. Thanks everyone.
Another alternative is to have an alias with some specific dev dependencies and simply require them in dev inside a (try ... (catch ...)) block and do nothing if such a dependency cannot be required.
A caveat is that if some of such dependencies eventually end up being brought via some other deps, as transitive ones, you'll have dev logic executed in prod. So a separate flag is still useful.
yes. I could do that but i fear these kinds of try catch. If in case something goes wrong in loading dev dependencies in future this try catch can waste a lot of time.
If you want env-variables and env-specific configs (dev vs prod), lambda island's config library should be worth checking out: https://github.com/lambdaisland/config
I've used aero in most of my recent projects. Each key from my config matches an entry in an integrant topology so a running system is just the merge of the two. That way you can run different components for prod/test/dev with different values.