For me, getting started via dotnet tool was easy enough 💯

In terms of dependency resolution, will there be a way to say these are my jvm deps vs clr deps? Currently my deps.edn contains https://github.com/clojure/data.jsonhttps://github.com/clojure/data.jsonhttps://github.com/clojure/data.json for the jvm but will need https://github.com/clojure/clr.data.json to run on the clr.

I think another downside with cmdlet might be getting things working on linux and OSX involves more work

Ohh, also in terms of additional work for command-line parsing, I think https://github.com/borkdude/deps.clj/blob/master/src/borkdude/deps.clj might already have some of it done since it's a "A faithful port of the clojure CLI bash script to Clojure"

Yes, the PowerShell module that the Clojure team currently uses for clojure on Windows makes shelling out to clojure and cmd line parsing tricky. The Clojure core team was (and maybe still is) considering moving to https://github.com/casselc/clj-msi/releases or similar (which is an installer for a natively compiled deps.clj).

Given that the CLR tooling can be installed on macOS/Linux as well as Windows, perhaps not conflicting with the existing clj / clojure commands would be a good idea -- and based on my (limited) experience so far with the .NET stuff, I like the idea of a dotnet install command for the CLI (which would work for both Windows and for macOS/Linux, yes?). The Powershell stuff we have for the CLI so far is pretty nasty (and is hopefully going away)...

I would lean toward dotnet install also. With the PowerShell approach clojure and clj are only shell aliases so they can’t be invoked in a cmd shell or via CreateProcess, Process.Start, etc. Having a tool that can actually be somewhere on the system/user PATH is preferable imo. I don’t see any reason to add the complexity of an MSI installer given how easy it is to do a tool install, but I’d be happy to make a version of the clj-msi installer for clr if there is interest.

dotnet tool , easy to install and makes things very accessible

@U45FQSBF1 if you have to write the command line parsing in C#: https://learn.microsoft.com/en-us/dotnet/standard/commandline/get-started-tutorial

Thanks for all the input. Valuable perspective on how the decision affects usability in ways that I had not considered. Sounds like dotnet tool or dotnet install. (I'm always pleased when the consensus points to my preference. 🙂 ) @UBN9SNVB4 -- System.CommandLine was my bedtime reading. (I like how it's been in beta for 2.5 years -- and also has almost 16 million downloads over that span.)

@U1G869VNV re your question on clr-deps vs jvm-deps came up in conversation I was having with @U04V70XH6 on the cross-platforming of tools.cli The root problem is that the edn reader does not support reader conditionalization. Sean had some interesting approaches, but after Sean convened somewhere an enclave of wizards, the conclusion was that the simplest approach would be to have ClojureCLR look first for a deps-clr.edn (actual name TBD) with a fallback to deps.edn on the assumption it might have git/local deps only. a deps-clr.edn really would only be needed on a cross-platform library.

@U1G869VNV and thanks for the pointer to https://github.com/borkdude/deps.clj. I had run across it before but had forgotten about it. Nor realized that the present circumstance is where it would reveal its utility. Always nice to read through @U04V15CAJ’s code, even more so when the alternative is bash or PowerShell scripts.

Have you seen this? It's based on deps.clj /bb as well: https://blog.agical.se/en/posts/how-to-create-a-really-simple-clojureclr-dependency-tool/

The code of deps.clj is more or less a direct port of the bash script, I didn't write it to produce nice-to-read code :)

deps.clj supports -Sdeps-file so you could do -Sdeps-file deps-clr.edn

@U04V15CAJ: @U0ETXRFEW has been turning out some great code. I'll be stealing what I can. Not full deps and its dockerized, so I need to fill in some gaps for the more general use case. Re -Sdeps-file -- I was thinking not to put the burden on the user. Wouldn't it be better to bake it in?

@U45FQSBF1 I don't know what you are exactly building, but let me add this: The powershell installer will disappear as the official option at one point in favor of a flavor of a standalone executable based on deps.clj which is thing thing: https://github.com/casselc/clj-msi The reason is that a powershell module isn't great for interoperability and there's more reasons that you can find in #clj-on-windows

@U45FQSBF1 If it's helpful, we could add clojure CLR support to deps.clj (not sure if that is helpful, but I'd be open to it)

@U04V15CAJ the goal is to provide the same functionality as the cli/`clojure` CLIs with deps.edn configuration. We need the dependency chasing and the equivalent to classpath building. Looking at procurers for local, git, and nuget, but not supporting mvn, poms, etc.

alright, so basically building tools.deps for clr from scratch (ah yes, you can re-use the git stuff)

Yep.. I already ported tools.gitlibs. (https://github.com/clojure/clr.tools.gitlibs)

@dangercoder System.CommandLine has a very specific notion of what a command line should look like. Mostly follows POSIX standards, it appears. The specified syntax for the Clojure CLI tools does not appear to follow that standard. I do not see how to map one to the other. Leaving the choices: (1) use System.CommandLine and have a different syntax for the ClojureCLR version. (2) Follow the Clojure CLI tool syntax. For those who want/need to go both ways, I suspect (2) is the only friendly option. Given that we have examples from the PowerShell script and from @U04V15CAJ’s deps.clj, I doubt I would save (much) time over option (1).

True, the Clojure CLI is pretty quirky in places... But it is also a relatively small "parsing space"...