Huh... I may have a usage for the second one
Hi everyone, and thank you again @borkdude for such a great tool... I'm writing clojure again (in an elixir shop now)..
Anyhow how can I check to see if https://github.com/grammarly/omniconf could be supported by babashka.. Many people don't like it since it stores all state in a global atom like integrant, but for scripting it's just fine and it does all of the property/env/cli merging magic in a very explicit way
It has some unfortunate dependencies on aws libs I'm afraid which would require a PR I think
since using s3 is completely optional IMHO
@nicolas.estrada938 How I would test this is:
$ cat /tmp/omni.clj
(require '[babashka.deps :as deps])
(deps/add-deps '{:deps {com.grammarly/omniconf {:mvn/version "0.4.3"}}})
(require '[omniconf.core :as cfg])
This gives me:
$ bb /tmp/omni.clj
----- Error --------------------------------------------------------------------
Type: clojure.lang.ExceptionInfo
Message: Unable to resolve classname: StackTraceElement
Phase: analysis
I'm opening an issue 😉 Or maybe I'll just fork it
they could make this function optional for bb possibly using a reader conditional, #?(:bb ... :clj ...)
@nicolas.estrada938 There is a temporary hack possible:
(ns omniconf.core)
(defrecord StackTraceElement [])
(require '[omniconf.core :as cfg] :reload)
This loads to another issue:
Unsupported binding key: :forms
Not sure why this is. Perhaps a bug in babashka...I'm actually suprised you were able to port so many libraries without the core ExceptionInfo
class and the underlying java.lang
classes
ExceptionInfo is available:
$ bb -e 'clojure.lang.ExceptionInfo'
clojure.lang.ExceptionInfo
A lot of Java classes are available. Just not all, it's by choice
Not sure what the issue is with :forms
, this seems to work in bb:
(defn foo
"docstring"
{:forms '([& ks value] [ks-vec value])}
[& args])
Of course, I understand, I'm just surprised that you were able to manage Throwables
without importing all of the gunk that goes along with it 😅 No sweat
Feel free to post an issue about it. So far we didn't include StackTraceElement
but if the size doesn't grow too big it might make sense for compatibility.
I more curious how other compatible libraries are able to work, before opening an issue I'll look into other libs like cprop
and docopt
But thanks! 🙏
cprop and docopt should both work
I see the issue with :forms
is:
(defn populate-from-env
"Fill configuration from environment variables. This function must be called
only after `define`. If `quit-on-error` is true, immediately quit when program
occurs."
([quit-on-error]
(@logging-fn "WARNING: quit-on-error arity is deprecated.")
(populate-from-env))
([]
(try-log
(let [env (System/getenv)
kvs (for [[env-name spec] (flatten-and-transpose-scheme :env @config-scheme)
:let [value (clj/get env env-name)]
:when value]
[(:name spec) (parse spec value)])]
(@logging-fn (format "Populating Omniconf from env: %s value(s)" (count kvs)))
(doseq [[k v] kvs] (set k v)))))
{:forms '([])})
This lib using a trailing metadata map which is not recognized by bb at the momentif I get rid of all of those and get rid of StackTraceElement, then the code does work
so forking might make sense if you're really keen on this specific lib
At work we are using this library: https://github.com/dunaj-project/crispin
it was recently made compatible with bb
Ok I'll look into it 😉
I'll make issues for the omniconfig things
or perhaps this syntax should just die:
(defn foo
([])
([_ _])
{:x true})
clj-kondo also doesn't recognize itRather one should just write
(defn foo
{:x true}
([])
([_ _]))