This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-10-02
Channels
- # announcements (13)
- # babashka (42)
- # beginners (29)
- # calva (39)
- # cider (15)
- # clerk (10)
- # clojure (67)
- # clojure-europe (18)
- # clojure-hungary (2)
- # clojure-nl (1)
- # clojure-norway (12)
- # clojure-uk (7)
- # clojuredesign-podcast (14)
- # clojurescript (19)
- # datalevin (1)
- # datascript (5)
- # emacs (4)
- # events (2)
- # fulcro (5)
- # graalvm (5)
- # hyperfiddle (23)
- # incanter (3)
- # jobs (2)
- # lsp (8)
- # missionary (15)
- # off-topic (45)
- # portal (41)
- # practicalli (1)
- # re-frame (3)
- # reitit (6)
- # releases (2)
- # remote-jobs (1)
- # sci (1)
- # shadow-cljs (35)
- # solo-full-stack (8)
- # tools-deps (4)
Is there anything I should be wary of when switching from Leiningen to "deps" on the dependency resolution and artifact builds aspect. I already transitioned to "deps" and everything seems to be running the same when I produce an uberjar artifact.... Is there a way I could compare the transitive dependencies between both builds however because I imagine "deps" and Leiningen do different things here....
you jar tf the.jar | sort
and then diff the output before/after
Amazing! Thanks
I expect you may find some minor differences, particularly in META-INF
for deps, there are ways to produce deps trees from both approaches. I'm not sure if there is a way to get an actual list out of lein, but from deps, use clj -X:deps list
You can do lein deps :tree
with lein but the output is slightly different than deps so its hard to compare. I will look at the jars first manually, I did not know you could do that with the jar tool
if you add :pedantic :warn to the Lein side, you may see areas that would benefit from some explicitness (and that may coincide with any possible deps<>lein diff)
Oh thanks!
if you want to understand the gory details of deps expansion and version selection, https://clojure.org/reference/dep_expansion. Maven is essentially a top-down, breadth-first expansion, keeping the first version of a dep that it encounters, whereas as tools.deps tries to select the "newest" version that it can. In both cases, versions set at the top-level will win, so that's always a fallback to force something to happen. In practice, I find that in many cases the results are either the same or negligibly different (you get a different version of deps of deps like logging libs)
each has a way to get a classpath. The classpath entries include versions. Parsing and comparing that might be the easiest
/Users/dan/.m2/repository/amalloy/ring-buffer/1.3.1/ring-buffer-1.3.1.jar
there’s a prefix, group/artifact/version and parsing that might be the easiest way to find the libs that are the same and the ones that are different or missing
Generally when porting lein deps to clj deps you end up being able to drop a lot of exclusions and have more predictable deps resolution.
The only tricky cases with clj is when it encounters different coordinate types (git vs maven vs local) for the same artifact. But it’s quite explicit about these
Today I started using tokens like #__
and #______
for these forms:
(case key
:foo (for-thought)
:bar (ba-rella)
#___ (default))
and
(def lst [#__
1
2
3
#__])
for alignment and avoiding reformatting purposes.
Where #____
is short for #_ ___
of course.
Seems like nice trick for when you want that control.
I saw @seancorfield do this in a video:
(comment
(some thing)
,)
but Calva will always eat that comma on reformat. Though Calva does put the comment closing paren on its own line.
Do others have similar special formatting tricks?
i've seen
(comment
...
#_())
before too, which is what I use :^)I started with #_ ()
then #_ 1
then #_ _
then #__
then #_______
(in lightbulb order 🙂 )
I've also been doing lines like:
#_#_#_#_#_
to disable the next five forms (instead of prefixing each form individually)I had read about #_#_
somewhere for ignoring key/val pairs and then tried it on 3 or more and it's generic in that way.
Hello, I am using https://github.com/kkinnear/zprint for formatting with a global .zprintrc like this: {:map {:comma? false} :width 110 :style [:how-to-ns :community :respect-nl]}
That comma ,
was an old workaround for an issue that Calva has long-since fixed. It is not needed (and in fact is counter-productive now, as you've discovered).
Ah I didn't know (or forgot) you used Calva. I don't use the comma trick but the idea of using ignorable syntax forms for formatting control stuck with me.
My general position is "don't fight the formatter". Let it do its thing and don't use weird hacks to "force" you're own preferences onto formatting: you'll mostly just confuse other readers of your code.
this is dev stuff, when the formatter won't shut up
I really don't like your case
hack in particular. It's misleading at a glance because it looks like you have six argument forms and no default -- so you are defeating people's common understanding of code-at-a-glance.
I use the proper formatting when I'm done
I don't like the default action aligning to the left,
compared to cond
's :else
to me it doesn't look like 6 args at all
You can use it to see errors of test form evals and also shorter that #__
. Love it!
Interesting idea -- I haven't seen that suggestion before! I have a hot key bound to display the last exception in Portal from anywhere (so I never need to type or eval *e
).
I’m using this for rich comments:
(comment
:rcf)
And Calva’s command for adding rich comments creates them like that too.
Love the idea of keeping *e
in there for handy reach. You could try using commas to take up space, instead of #_, for example in your case form. I sometimes use commas when my key-val pair in a map is very wide and running off the edge of the screen. It helps guide my eyeballs especially inside a gnarly destructuring.
(let [{{:acme/keys [a b c e]} :level-2} :level-1}
,, <some-very-wide-value>
...]
...)
@UTFAPNRPT I think the issue is that some formatting tools treat commas as actual whitespace and reformats it?
I see that may be a problem. Happily in Calva it has left them alone for me. Unless I hit backspace, for example, with the cursor right in front of <some-very-wide-value> then it deletes all the whitespace and brings the value up on the same line as the map, which was a surprise the first time it happened, but I came to realize it was “the right thing to to”.
@UTFAPNRPT the comma works for me here (and Calva doesn't eat it):
I like it, thanks!
Calva does eat this comma on reformatting:
(comment
(stuff)
,)
but it's not needed anywayCalva eats these commas too:
[,
foo
bar
baz
,]
->
[foo
bar
baz]
so I would still use
[#__
foo
bar
baz
#__]
when I want Calva to leave my list items alone for a while.I know it's not actually Calva that is responsible for the formatting, but you know what I mean...
become one with the default formatting options 🙂
still eagerly awaiting for clj-fmt to get associative formatting (which zprint has iirc) a la
{:one 1
:two 2
:three 3}
@seancorfield I already said I'm not avoiding the defaults (much).
I know, I'm just teasing at this point :rolling_on_the_floor_laughing:
@U0482NW9KL1 not sure what you mean. The auto-align of values?
Calva has that as an experimental formatting BTW.
how do you turn it on?
Calva is responsible for the formatting, I would say, even if we use cljfmt for it. The reason some commas are eaten and some not is because comma is whitespace and, depending on your settings, the formatter will remove leading and trailing whitespace.
Neovim/Conjure native-full-lifer here 🥲
i love it, but itd be nice to have the attention calva does
Calva has a command for vertical align of bindings. It’s pretty buggy. I don’t recommend using it.
I've been all vim for 20+ years but am now loving vscode (and calva)
Then again, I don’t fancy bindings being formatted like that. It creates too much whitespace noice in diffs.
{:a 1
:b 2
:long-thing 3}
=>
{:a 1
:b 2
:long-thing 3}
Calva format and align as a specific action from the command palette.It can also be enabled in the formatting settings. :align-associative?
, I think it may be.
In fact, that’s what Calva does on that command, (-> config (assoc :align-associative? true) …)
or some such.
Oh? I didn't know it could be handled automatically... not sure if I'd want it on every let
or hash map but it is nice that it can be asked to do it...
Ah, yikes, yeah...
(throw (ex-info "Incompatible types found in config-merger"
{:a a :b b :a-type (type a) :b-type (type b)}))
=>
(throw (ex-info "Incompatible types found in config-merger"
{:a a
:b b
:a-type (type a)
:b-type (type b)}))
Calva is using an old fork of cljfmt for this. And I have given up on even trying to keep it up-to-date with changes in cljfmt. So it has old cljfmt bugs, as well as misses new cljfmt features. And the feature itself has bugs too. With some luck the new PR for adding the feature is going to merged soon. James Reaves wanted to have a last look at it, last heard.
@U0482NW9KL1 fwiw the vim support in vscode is pretty solid. Otherwise I couldn't do it.
i did use VSCode back in the day, as a step on my text-editor pilgrimage, it is nice, but my dearest nvim (with my custom AstroNvim conf) has so much that I don't want to leave behind ❤️