Clojurians Log v2

Can't you override it to point to local JAR? The sources JAR file?

Since we're getting a lot of depstar questions here, I created a dedicated channel for support/questions/etc. Also for clj-new.

@dominicm you can also use classpath overrides with nil. I’ve used this for creating babashka uberjars (see its README and look for uberjar)

goodmorning, please advice how I can turn off the OmitStackTraceInFastThrow?

clojure -A:app -J "XX:-OmitStackTraceInFastThrow"

clojure -J-XX:-OmitStackTraceInFastThrow

thanks! it is all about the order

np

In clojure pre-release (1.10.1.672) it seems that the -X flag does not download dependencies specified in the alias :extra-deps section. Is this the correct behavior? From my interpretation of "-X now supports multiple aliases, aliases with other argmap options like :extra-deps, and ad hoc functions" I would have thought deps would be downloaded

is that in combination with -A?

No, just by itself. I understood -A was being depreciated, so am trying to understand the scope of using -M (which seems fairly clear) and -X which I am still confused about (from a users ponit of view)

@jr0cket that is intended to work, so could be a bug

To temporarily swap out a git dep for a local dev version, am I normally better adding an alias with :override-deps in it to a :local/root, or adding :classpath-overrides to my ~/.clojure/deps.edn ?

@rickmoynihan I usually use an override-deps (actually extra-deps because it's the same otherwise) in ~/.clojure/deps.edn because: • Nobody else can use it - has my homedir in • Most people on my teams aren't contributing to those other libraries anyway. It's less reusable than one would think

yeah for both options I’m talking about adding it to ~/.clojure/deps.edn… trying to understand which way is better.

One (`:override-deps`) effects resolve-deps and the other make-classpath right?

Practically though; aren’t they both equivalent?

I think for your case, they're essentially equivalent. I'd go with extra-deps just because it's more famiilar.

except :classpath-overrides assumes the lib only introduces a single classpath root, is that right?

so e.g. it would potentially miss including resources etc

https://github.com/clojure/tools.deps.alpha/blob/f94815dd55bdf5eb30ac8fa075c39e757cbbcca5/src/main/clojure/clojure/tools/deps/alpha.clj#L321 yeah 🙂

Exactly, yeah

Re command line args, I have one tool that only has one CLI argument, --opts in which you pass a Clojure map. For that tool I think it made sense and it also simplified command line parsing, possibly also easier to keep it non-breaking. I'm not suggesting that other tools do this, but works for this one particular thing.

clojure -A:carve --opts '{:paths ["src" "test"]}'

I suppose the clj way of doing that is would be clj -X:carve :paths '["src" "test"]'?

I guess so, but if we're going to use quotes, why not quote the whole thing anyway

I mention it only because I think this is what clj is trying to make the standard for cli tools. While I personally think --path src --path test would be the best, standards are better than better.

or :paths src,test since comma is whitespace in Clojure, but not in bash?

$ bb -e "*command-line-args*" -- :paths src,test
(":paths" "src,test")

You're thinking in Clojure 🙂 I'm thinking of bash. Admittedly, my answer was without context. Generally I'd much prefer an api where paths was the & args at the end so I could just do:

clj -X:carve dev-*

(which expands to clj -X:carve dev-src dev-resources dev-etc)

If bash would expand that comma separated, then it would work as passing one value.

Anyway, it doesn't.

Yeah, if keywords would separate other values then :jars *.jar :paths src* would work

unless your dir starts with a colon :)

but I guess using a comma as explicit separator works:

$ bb -e "*command-line-args*" -- :foo t* , :nums 1 2 3
(":foo" "tags" "test" "test-resources" "," ":nums" "1" "2" "3")

This doesn't work in powershell (no expansion, comma is gone)

PS Microsoft.PowerShell.Core\FileSystem::\\wsl$\Ubuntu-20.04\tmp> cd C:/Temp
PS C:\Temp>  bb -e "*command-line-args*" -- :foo t* , :nums 1 2 3
(":foo" "t*" ":nums" "1" "2" "3")

Finally, cmd.exe (no expansion, preserves comma)

C:\Temp>bb -e "*command-line-args*" -- :foo t* , :nums 1 2 3
(":foo" "t*" "," ":nums" "1" "2" "3")

Yes, it does work on a clean install of Clojure CLI with the ~/.clojure/.cpcache removed. This is making much more sence now. Thanks.

No idea how cmd.exe handles wildcards. Ultimately there's some platform specific tweaks to match the ergonomics of a platform you're on.

https://superuser.com/questions/1308329/move-folders-using-wildcard#1308364 welp

https://docs.microsoft.com/en-us/cpp/c-language/expanding-wildcard-arguments?view=vs-2019 apparently you have to use a custom routine or something... gosh

I guess there's a reason WSL2 is getting popular

But also - this is what people on cmd.exe expect. That's fine and while I don't understand it, if that's what makes sense for their OS then fine.

I listened to a podcast by someone who is working on the new Terminal app. She said that they couldn't change cmd.exe's behavior because that would be breaking for lots of people. But everyone basically agrees that it sucks.

Making the cmd.exe window smaller will make it faster, because there is less rendering, which is blocking

ok sorry, got a little bit off topic

Getting back to clojure/clj command line arg compatibility, this is not helpful right now, but I am curious. If we could go back in time would these tools have been better initially named something like clj-alpha1 and clojure-alpha1? This would have drawn attention to their alpha-ness and also allowed a path for introducing breaking changes.

Then again maybe not… this would have implied clojure itself is alpha.

Tricky little problem.

The help could have mentioned the word alpha at least somewhere. From and end user's perspective, it's hard to see this is alpha, you'd have to know what .jar it's calling underneath which has alpha in the name. This entire page doesn't mention alpha neither: https://clojure.org/guides/deps_and_cli

I just got a bug report against the new version of clj-new and it's obviously broken but it leads me to a question about t.d.a and migrations: clj-new uses t.d.a to resolve coordinates for templates and it was using t.d.a 0.8.677 and the clojure.tools.deps.alpha.reader namespace with default-deps and read-deps. I updated it to 0.9.782 and switched the code over to pull in the runtime basis... but of course that doesn't exist in the new CLI! Doh! I could revert to 0.8.677 and continue using the old logic, but I was wondering if there was a way in 0.9.782 to get at that same logic so that utilities could run with the basis, if it exists, else fall back to the equivalent of (read-deps (default-deps))? Mostly a question for @alexmiller I guess...

Those functions now exist in the tools.deps.alpha namespace

Or their equivalents - there were some name changes etc

Hmm, it looks like some of the logic for finding deps.edn has moved into the CLI script, and is no longer in t.d.a?

No, should all be there

Shape is a little different

OK, I'll keep digging...

Sorry, not at a computer to be precise

It’s just root-deps and user-deps and ./deps.edn

Read and merge

find-edn-maps was what I needed so I think I'm good now...

For anyone else working on t.d.a-based tooling who wants to leverage 0.9.782 but continue to support older CLI versions, here's what I ended up with for the basis:

(delay (if-let [basis-file (System/getProperty "clojure.basis")]
           (-> basis-file
               (io/file)
               (slurp)
               (edn/read-string))
           (let [{:keys [root-edn user-edn project-edn]} (deps/find-edn-maps)]
             (deps/merge-edns (filterv some? [root-edn user-edn project-edn]))))))

i have a tool that does something similar -- though it doesn't use anything like --opts before the string. it's nice to not have to decide on command line arguments when you don't know what option and arg names are likely to be used more often.