Clojurians Log v2
clr
Status update: • nREPL -- since I announced the alpha of clr.tools.nrepl, intrepid adventurers have given it trial by fire by running it against Calva in VSCode. I think perhaps the library is ready to publish for real. Thanks to @pez for his https://github.com/PEZ/clojure-clr-starter , mentioned previously in this channel and blogged about https://blog.agical.se/en/posts/how-to-create-a-really-simple-clojureclr-dependency-tool/. Thanks also to @terry.poot for distilling her experiences with VSCode/Calva/ClojureCLR into some issues for clojure-lsp and clj-kondo to improve support for ClojureCLR. We are well along the way of providing a decent IDE experience for ClojureCLR. • Deps & CLI -- My current focus is to bring all of the goodness of https://clojure.org/reference/deps_and_cl to ClojureCLR. There are lot of pieces to this: being able to read deps.edn files and build dependency graphs; download required libraries; construct (the ClojureCLR equivalent) of classpaths; install the CLI tools; provide the CLI tool functionality. The Clojure version supports so-called procurers for three types of library: Maven, Git, and local. We'll replace Maven with a procurer for Nuget repos. I think I have it narrowed down to porting these libraries over on the clojure github repo: tools.deps; tools.deps.cli; tools.deps.graph; tools.build; tools.tools, brew-install; tools.cli; tools.gitlibs. Yeah, that's a lot. The last one here I ported first -- https://github.com/clojure/clr.tools.gitlibs . I think it's ready to go, though I haven't officially made a release yet (despite what the README says). I'm about 90-95% done with tools.deps. There is no official repo yet. You can check out where I am at https://github.com/dmiller/clr.tools.deps. One of the problems finishing this one is proper testing. It currently runs all the tests that don't involve maven. Unfortunately, all the tests for one piece of functionality uses maven dependencies only. I don't have an equivalent web of dependencies to traverse in the real world. So one thing I'll be doing next is to go through all the existing libraries I support and deps.edn-ify them. So there will be new releases of almost everything. There are some significant design decisions to be made, particularly with respect of the role of NuGet. I'll start another thread with some thoughts on that and with a request for feedback. • Documentation -- You all are welcome to think about this one. Jump in any time.
I forgot: tools.cli is done also. We just needed to do some conditionalization in the existing code and it worked. Thanks to @seancorfield for taking care of that. (There will be a problem with the deps.edn files on any shared repo. I don't know how to handle that yet.)
Could you elaborate on that "problem with the deps.edn files on any shared repo" issue?
I misspoke on tools.cli, I think. Confused with tools.tools which I had just been looking at. For tools.cli, all the :mvn coordinates appear to be in aliases. I suppose I can just add different aliases that use other coordinates (likely :git) -- for :test, :runner, etc. add entries for :clr/test, :clr/runner, etc. Now for tools.tools, there are :mvn coordinates in the :deps. :deps is a fixed keyword, I don't think I can define my around that. And in CLR land, we won't be support the maven procurer. So I need to express the dependencies in :git coordinates (most likely). How can we have multiple sets? I really don't want to have to special case a top-level designated keyword like :deps. (for a variety of reasons, one of which is making sure I covered all possible places in the code of all these libraries where it might matter.)
For shared versions you could use a :clr alias and :override-deps in most cases I think. We should discuss in more detail when I'm at a computer instead of on my phone
Thanks for all your work on this, David! I’ve been swamped at work lately, but I’m excited to try this all out once I get the time!
@seancorfield More discussion would help. I must admit I don't know all that's possible in this space.
In ClojureScript, several clojure. namespaces are automatically mapped into their cljs. equivalent - did that also happen for cljr. namespace mapping in ClojureCLR?
no. ClojureCLR maintains clojure. namespaces. (If I'm understanding the question.)
Ok, so you have clojure.test not cljr.test etc? Good to know, thanks.