Clojurians Log v2

The README lists 0.1.4 as current so I was very puzzled when nothing worked! It was only when I double-check the commits I saw 0.1.5 was current and had renamed .cli-config to .cljconf Other than that, it was super-smooth sailing!

Having :defaults and :overrides perfectly matched what I needed: here's the commit that added the cfg/config call https://github.com/seancorfield/deps-new/commit/9e44a8c76483418acb723fd7bb987d3d72d0b9f3#diff-a7245dfffb5fb0a8b0e7a0f25ea6f8ea5383f9f8aedc13a84c5c57bb6f5b6ab8

I had to decide whether I wanted to use io.github.seancorfield/deps-new or org.corfield/deps-new and after trying both, I settled on the latter (ns/lib matches the docs, but that's not what the CLI REPL uses BTW: it uses group/artifact).

Actually, the t.d.c docs are a bit contradictory: Tools are identified by a qualified lib symbol (e.g., http://my.org/my-tool). The config file lives at <location>/.cljconf/<lib-ns>/<lib-name>.edn group/artifact in the first, ns/lib in the second.

Both API and Data sections start out saying <lib-ns> but then all the examples say <my-org>

iirc the intention here was group/artifact in all cases

but it's been a while and I don't think what you're doing is bad as it still is sufficiently distinguishable

I own the domain, so I'm going to standardize all of my config on that, despite having a mix of io.github.seancorfield and com.github.seancorfield groups. And Rephrase is org.corfield/rephrase 🙂

(the only reason I tended to go with the *.github.seancorfield group was for git deps...)

Might want to update the t.d.c readme to be consistent everywhere...

Once I'd twigged to the 0.1.5 release, it was a great experience. Really well designed for the obvious uses. Thank you!

As more projects start using this approach, and perhaps start having deps.edn and code in their data directory, it would be nice to have this piece of clojure-cli.repl packaged into t.d.c in some generic form... https://github.com/clojure/clojure-cli.repl/blob/main/server/src/clojure_cli/repl/server.clj#L148-L178

not sure I'm totally following the code here but seems like a reasonable kind of thing to ask. what is the intent from an external user pov? I guess I'm not sure why we're putting stuff on the classpath vs reading as files here

Hmm, perhaps I need to read it again in more detail, but I'm going out for dinner right now. Will follow-up later/tomorrow.

open to ideas, thanks!

Okay, I've made sense of it now: • The clojure-cli.repl data directory has a deps.edn file • This code adds to the classpath of the tool • Anything from the user or project config's deps.edn, e.g., src, so subsequent code in the tool can load & run code from the user's config • The alias here is specific to the tooling: the CLI REPL lets you specify additional server-only or client-only aliases (and therefore deps) So, for tooling in general, the alias is optional (and in most cases not needed), but the ability to add code in the user- and project-level data directory to the classpath for the tool is the useful part. With deps-new, for example, this could be used to store commonly-used templates (or even just template dependencies), rather than having to create a separate repo and specify a complex command-line argument to locate it.

That all said, since it requires Clojure 1.12+ anyway, using add-lib and :local/root would be a simpler solution when you don't need the alias.

there may be other better ways to solve this

For a tool to add "global" code to the classpath from the user/project config data directories? Sure. I don't much care about the mechanism, but the capability is useful. Using add-lib with :local/root seems a reasonable approach tho' (without aliases), for now?