Clojurians Log v2

New version of deps.clj, a port of the clojure bash script to clojure: https://github.com/borkdude/deps.clj/releases/tag/v0.0.12 - catch up with 1.10.3.814

messing around with this neat tool I found (https://gist.github.com/ericnormand/6bb4562c4bc578ef223182e3bb1e72c5) to make .clj files into scripts. Curious if it's possible to use either -X or -m or something to cherry pick a function from the script.

#!/bin/sh
#_(

   #_DEPS is same format as deps.edn. Multiline is okay.
   DEPS='
   {:deps {}}
   '

   #_You can put other options here
   OPTS='
   -J-Xms256m -J-Xmx256m -J-client
   '

exec clojure $OPTS -A:strapped -Sdeps "$DEPS" "$0" "$@"

) ;; code goes below here

(defn test []
  (println "[+] test successful"))

(defn -main []
  (test))

I've tried ./test.clj -X test, ./test.clj -M -m test, ./test.clj -m, ./test.clj -m test, ./test.clj -M, ./test.clj -M -m , ./test -X test/test

@goomba Since it invokes the script directly via the clojure command, you cannot use other main- or exec- options with it, as it stands.

ohhhh

would require clj?

No, clj is just a wrapper around clojure that adds rlwrap.

(`clj`/`clojure` are otherwise interchangeable)

ah

You’d need to have the directory containing the script as a :local/root dependency and then you could invoke functions in it via -X but that’s a bit hacky.

I'm also a bit hacky haha

@goomba Something like:

(! 962)-> ./unbalanced.clj -X unbalanced/test :foo '"bar"'
WARNING: test already refers to: #'clojure.core/test in namespace: unbalanced, being replaced by: #'unbalanced/test
[+] test successful {:foo bar}
(! 963)-> cat unbalanced.clj 
#!/bin/sh
#_(
   #_DEPS is same format as deps.edn. Multiline is okay.
   DEPS='
   {:deps {} :paths ["."]}
   '
   #_You can put other options here
   OPTS='
   -J-Xms256m -J-Xmx256m -J-client
   '
exec clojure $OPTS -Sdeps "$DEPS" "$@"
) ;; code goes below here
(ns unbalanced)
(defn test [arg-map]
  (println "[+] test successful" arg-map))

:paths should really be dynamically constructed to be the folder for the script.

Notes: needs a ns form for -X invocation (so it has a defined namespace); removed "$0" since we don’t want to execute the script directly; added an arg to test so it can be called via -X.

I must be missing an assumption

using

:deps {     
        org.clojure/clojure      {:mvn/version "1.10.2-alpha4"}
        }                                              
               

does it require a deps.edn in the same dir?

What is your clojure version? clojure -Sdescribe

oh, fascinating

{:version "1.10.0.411"
 :config-files ["/usr/local/lib/clojure/deps.edn" "/home/jay/.clojure/deps.edn" "deps.edn" ]
 :install-dir "/usr/local/lib/clojure"
 :config-dir "/home/jay/.clojure"
 :cache-dir ".cpcache"
 :force false
 :repro false
 :resolve-aliases ""
 :classpath-aliases ""
 :jvm-aliases ""
 :main-aliases ""
 :all-aliases ""}

That is very old (and does not support -X). The current version is 1.10.3.814

wow, great catch, had no idea. I thought my ~/.clojure/deps.edn would take precedence, but I suppose not 😮

Not sure what you’re asking about. That’s the user deps.edn and, yes, it factors in.

(unless you pass -Srepro)

this file /usr/local/lib/clojure/deps.edn has a different clojure version than my ~/.clojure/deps.edn , I think. Sorry for confusiion

its not the version of the jvm hosted language that's an issue. its the version of the command line program clojure which assembles a classpath and calls an entrypoint. That command line clojure is too old to understand the -X command line argument

ahhhh

time to upgrade!

Clojure CLI version != Clojure language version.

works like a charm!!!!!!!

go team!!!! 🔥 🎆

thank you!!!

The prefix portion of the CLI version indicates the default version of Clojure it would use (1.10.0, 1.10.1, 1.10.2, 1.10.3) and the last segment is the commit count for that release.

aha! working great now 🙏

Is there any precedent of tools that need tools.deps.alpha for downloading deps and calc classpath that also put their non-deps-related tool config in deps.edn? E.g. shadow-cljs has a config file which allows :deps true to resolve deps from deps.edn, but it does not store its own config in deps.edn. Are there any tools who do? Is this encouraged / not recommended / neutral?

@borkdude My feeling is that given the alias-as-data thing that has crept into deps.edn, we will start to see tooling be passed one or more keyword-valued exec arguments and it will be common for the tool to then lookup those keywords as aliases in the project basis and use the data structures those aliases point to. depstar already does this, deps-deploy has an open PR to add that.

That allows users to name additional tool config in deps.edn however they want and then communicate that name to the tool via a keyword-valued exec arg.

ok, but depstar is a dependency-centric tool, so it's more obvious there probably

You can also specify a keyword for the whole :exec-args thing and that is looked up as an alias by the CLI -X machinery.

I think any tooling that you run via CLI can reasonably assume it could look up aliases in the basis to get configuration data.

But I strongly believe it should be via an exec arg passing a keyword and not a hard-code alias name.

what if the tool isn't invoked via the CLI but maybe via a binary.

If you pass the tool a keyword argument that tells it what alias in the basis to use, I think that’s reasonable.

On the other hand, if all kinds of tools start saving their config in deps.edn, this file could become pretty big and tedious to parse on every tool invocation

I think that depends on just how much config various tools have. Having some sort of “build” config in deps.edn seems reasonable but maybe a tool that has a very open-minded config (clj-kondo) should not use deps.edn for that and should keep it separate?

In this case I'm thinking of a task runner (like make, npm scripts, just, etc) in babashka that you configure in EDN. It is not being invoked through the clojure CLI but it can use tools.deps.alpha for itself. This will capture commonly invoked commands, including invocations of the clojure CLI itself, so you don't have memorize those or write bash scripts to wrap them.

So it leans on tools.deps.alpha but I don't think it will read from a basis file using an alias name for example.

it is discouraged to add top-level keys to deps.edn

But clj-kondo is also a good example: clj-kondo could read from your deps.edn, but it doesn't necessarily belong inside deps.edn

doing so could break in the future, and would be unsupported

putting named data in :aliases is ok

understood. and what about an alias convention, e.g. tool X always reads from :aliases :tool-x ?

alias data good, novel top-level keys bad

alias data could be the name of a config edn file to read if you want to centralize definition but offload the contents

yeah, I think it's better to split it

why not use a ns?

I think I'll adopt the way shadow-cljs did it

FWIW deps.edn didn't exist when I started with shadow-cljs.edn but I would make the same choice again. I prefer having targeted configuration files over the all-in-one gigantic configs

Glad to have Alex confirm what I was saying there 🙂

FWIW I wasn't planning on adding top level keys to deps.edn, but if I went the alias way it would probably have been a fully qualified keyword unique to the tool. But I agree with thheller's remark. Thanks for the useful exchange.