Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2022-11-14

Channels

#tools-deps
<
2022-11-14
>
mkvlr08:11:54

there's no way to use an alias of a git dep, or is there?

vlaaad08:11:06

there is an issue to support it

mkvlr09:11:25

@U47G49KHQ thanks, I'll upvote it

socksy18:11:41

having problems with default-deps again. In one frontend project, using shadow-cljs + deps.edn, I successfully have the following: 

:cider-nrepl {:extra-deps {cider/cider-nrepl nil
                                      refactor-nrepl/refactor-nrepl nil}
                         :default-deps {cider/cider-nrepl {:mvn/version "0.27.4"}
                                        refactor-nrepl/refactor-nrepl {:mvn/version "2.5.1"}}}
this is overridden in my ~/.clojure/deps.edn here: 
{
  :deps {cider/cider-nrepl {:mvn/version "0.28.3"}
         nrepl/nrepl {:mvn/version "0.9.0"}
         refactor-nrepl/refactor-nrepl {:mvn/version "3.5.2"} }
}
in a new, backend project, I have the following: 
:cider-nrepl {:extra-deps
                {cider/cider-nrepl nil
                 refactor-nrepl/refactor-nrepl nil}

                ;; In theory this makes it possible to override them in your .clojure/deps.edn
                :default-deps {cider/cider-nrepl {:mvn/version "0.28.5"}
                               refactor-nrepl/refactor-nrepl {:mvn/version "3.5.5"}}}
when I run the backend project, it does not let me override the deps, but when I run the frontend project, it does. Any idea of a lead to fixing this?

socksy18:11:04

no idea what is relevant version information, but fwiw clojure versions in the frontend project are: 

org.clojure/clojure {:mvn/version "1.11.1"}
org.clojure/clojurescript {:mvn/version "1.11.60"}
shadow-cljs has :deps true, with shadow-cljs version of {:mvn/version "2.19.8"} (link to github tree as of that commit https://github.com/thheller/shadow-cljs/tree/dd7d5fd71398a60aaa204759b6e06fb6aefa8e2a) in backend project clojure version is the same, and ran via clojure -M:foo:cider-nrepl

seancorfield18:11:11

Pretty sure that's not how default deps are supposed to work. You'll get the newest version of a dep that is specified -- you can't override in deps with an older version.

socksy18:11:49

ah crumbs. That makes sense but totally breaks my use case

Alex Miller (Clojure team)18:11:05

can you just use :replace-deps ?

seancorfield18:11:31

Specifying :default-deps alongside nil deps is going to be the same as specifying those versions directly anyway. And specifying :deps in your dot-clojure file is going to add those deps to every project, even when you build JAR files etc. Do you really want CIDER/nREPL etc in everything you build?

🙏 1
Alex Miller (Clojure team)18:11:41

yeah, I was a little unclear if that was at the root or in an alias

socksy18:11:52

not an alias, since unfortunately the calls in both cases are wrapped in tooling that doesn't make it easy to pass in a custom alias :( I figured for builds I would just isolate them in docker anyway since who knows what people could have locally

seancorfield19:11:05

Q about classpath ordering: did we establish that t.d.a's classpath ordering is non-deterministic, with only the :paths guaranteed to be at the "front" of the classpath in some order? i.e., the classpath calculated on one machine can differ in order from the classpath calculated on another machine?

Alex Miller (Clojure team)19:11:57

More clearly: it should be deterministic

seancorfield19:11:59

Hmm, I was sure we'd had this discussion... back when the change was made to ensure paths ended up at the beginning of the classpath and not some "random" place within it...?

seancorfield19:11:29

Right, but I thought that was only to ensure paths were at the front, not to ensure a specific ordering consistent across machines...

Alex Miller (Clojure team)19:11:02

This was a long time ago now, but I am also sorting deps by tree depth and then by name, which should be stable

seancorfield19:11:12

For example, if the path to .m2 differs, isn't that going to create different hashes on the paths if they're put into a hash map?

seancorfield19:11:49

Ah, OK, so t.d.a classpath ordering is stable. Thank you. I'll go beat on the Polylith team about that then 🙂 Their computed classpath is not stable.

Alex Miller (Clojure team)19:11:39

I believe order will be extra-paths (in order), paths (in order), then deps sorted by tree depth then alpha

Alex Miller (Clojure team)19:11:17

I think I have a site issue from you to doc this better actually :)

seancorfield19:11:19

I got bit because Jetty, bless its heart, decided to keep the same class names across different group/artifact JARs so if you end up with multiple versions (with different coordinates), you can pick up the "wrong" class version...

laughcry 1