Me, trying to be smart and sneak in read-eval to deps.edn:
1. creates data_readers.clj
with {clj/eval clojure.core/eval}
2. creates alias with :key #clj/eval (requiring-resolve my-fn)
in :exec-args
clj_exec.clj: uses edn/read-string
that ignores data_readers https://github.com/clojure/brew-install/blob/fde9db19bfe92a315b81b5f56d290a6d37a91d89/src/main/resources/clj_exec.clj#L39
¯\(ツ)/¯
I think clj-exec is limiting by only accepting edn data. I want to pass a function, I don't want to add work-arounds that accept and auto-resolve symbols where exec function they expect functions as arguments
@vlaaad Whilst I share some of that frustration (after hours poking at the internals of Figwheel, Rebel Readline, and the cljs compiler itself), I think it would pretty dangerous -- I think it is reasonable for the function you invoke to have to do the requiring-resolve
because it's generally easy enough to write a wrapper that you can invoke (and have it invoke whatever you're trying to pass a function into).
I agree that read-eval is probably too dangerous for a problem I don't have a solution for, but passing function to a function should not be impossible with clj-exec IMO
What’s wrong with passing the fully qualified name? Don’t prepls repls and socket servers behave this way?
clojure.main/repl
expects functions, for example, so it can't be used from clj-exec
Yeah, that was similar to my use case: where I want a resolved symbol, which has to happen at runtime, hence a wrapper is needed.
We are working towards a solution to this greater problem
In particular, making vars autoresolve on read
Note, not symbols but vars
A release or two ago we changed var deserialization to do that
I took a pass at var resolution at that point as well but we decided to wait on it. That’s likely to be in scope for 1.11
https://ask.clojure.org/index.php/3810/clojure-var-tag-for-transmitting-var-identity?show=3810
Votes welcome :)
Upvoted! Thanks for detailed response
You’re not crazy :). We’ve been thinking about this for years