hi there, pardon if totally missed this (but google didn't give me any answers). my question is: is there an alternative to lein's pedantic? in tools.deps

@mpisanko No. It's also worth bearing in mind that the algorithm for selecting versions is different in t.d.a. so there should be fewer potential conflicts. Or at least, fewer counterintuitive version selections 🙂

I think there's still an undocumented :verbose true option you can add to deps.edn so that t.d.a. explains all of its decisions...

right, that's the premise of improved dependency resolution i guess. thanks @seancorfield!

Looks like :verbose needs to be under an alias, not at the top-level...

{:aliases {:v {:verbose true}} ,,,}

actually there are tools that can help you with this in clj

https://github.com/clojure/tools.deps.alpha/wiki/Tools is a big list

in particular, check out depot or deps-ancient

Those will detect old (outdated) deps in your project -- lein pedantic detects possible version conflicts (usually in transitive deps) and warns about them (and prevents command execution if any potential conflicts are present, as I recall) so it's not really equivalent to anything on that list...?

I think t.d.a.'s approach makes much more sense and you can either eyeball things with -Stree to see what actually got picked, but you can only see the potential conflicts if you ask t.d.a. to be verbose, as far as I can tell.

(we use depot at work, and it's very useful for flagging deps that could be updated -- but does not show potential conflicts)

Looking in more detail at some verbose output from t.d.a. I can see its decision process cuts off some paths that I think Leiningen considers... I'd have to try to repro in lein to be sure... (this has piqued my curiosity!).

Yes, confirmed. Example: deps.edn specifies Clojure 1.9.0 and seancorfield/next.jdbc 1.0.8. t.d.a. pins those versions because they are top-level and when it sees that next.jdbc depends on Clojure 1.10.1 it just discards that due to 1.9.0 being the top-level dep. Consequently, t.d.a. goes on to select spec.alpha and core.specs.alpha based on Clojure 1.9.0. When you put the same deps in project.clj and :pedantic? :abort and ask for lein deps :tree, Leiningen also shows the transitive dependencies of Clojure 1.10.1 and warns they conflict with Clojure 1.9.0's deps, suggesting exclusions (on next.jdbc) to exclude all three of clojure, spec.alpha, and core.specs.alpha (and then it aborts).

(if you tell lein to exclude org.clojure/clojure that is enough to satisfy it)

@alexmiller Please have a look at TDEPS-56 when you have time. I have posted a patch and an upsides/downsides table some time ago, and there was no further discussion on the topic.

@ghadi Yes, I wanted to know if there was already existing tool to manage dependencies before to begin development. I find this tool who do the job https://github.com/hagmonk/find-deps

Is it possible to use an alias to override a github library with a local root library?

{:deps {github-myorg/myrepo {:git/url "some-url" :sha "some-sha"}}
 :aliases {:local {:override-deps {myrepo {:local/root "/abs/path/to/my/local/repo/"}}}}}

^ doesn't seem to do what I want.

presumably because the lib names github-myorg/myrepo and myrepo differ

d'oh. It looks like I can just stop using the symbol github-myorg/myrepo for the GH dep and instead use myrepo as with the local dep. I didn't realize that was just a naming convention and not a requirement.

Extra-deps instead of override

but wouldn't that result in two deps with the same namespaces?

to be clear, this now seems to do what I want:

{:deps {myrepo {:git/url "some-url" :sha "some-sha"}}
 :aliases {:local {:override-deps {myrepo {:local/root "/abs/path/to/my/local/repo/"}}}}}

Yup, myrepo in the above is the coordinate for your dependency: the group and artifact ID, as if it were myrepo/myrepo -- and the coordinate has to match since that's what you are overriding.

(well, technically, the "coordinate" is the group/artifact and the version information but...)

So it isn't "just a naming convention" -- it has a specific meaning.

Thanks @seancorfield that clarification is helpful. I should have been more clear: I intended to write that I was under the false assumption that if a coordinate used the :git/url key in its version info that it had to have a group containing the github- prefix.

If you're not trying to override a "regular" dep with a git dep, then you can give it any unique name you want, but using your github organization (username) and the repo name means it's not likely to conflict with a "regular" dep.

If you're working with a regular dep (group/artifact) with a Maven version, you can just swap out the version part for a :git/url part or :local/root part and keep the same group/artifact to effectively override the Maven version with that git or local version -- and that will work even if it is a transitive dependency of something else you're depending on (since you'd have it as a top-level dep).

Does that help, or just make it more confusing @jrwdunham?

An example: https://github.com/seancorfield/dot-clojure/blob/master/deps.edn#L136-L149 -- that uses a git version instead of the Maven Central version of org.clojure/tools.deps.alpha

@seancorfield I am left a bit more helped and a bit more confused. So, in your example, since you are not declaring a top-level :deps for org.clojure/tools.deps.alpha, you use :extra-deps in your :deps alias to effectively override the Maven dependency that would be installed otherwise. Is that accurate?

I use :extra-deps there to ensure it is added (with that git version). :override-deps only takes effect if something else is bringing in that dependency.

(in this case, it becomes a top-level dep so even if something else brings in t.d.a. as a transitive dep, my selection takes precedence)

Has anyone had problems using s3 repos with deps under Java 11?

Some Cursive users are having problems which is reported as not being able to access java/sql/Timestamp, when using lein that’s usually resolved by upgrading the s3 wagon. But it looks like the deps version is baked in.

Is anything required to be added to the module classpath, or anything like that?

no, lots of people doing this, haven't heard any issues

java/sql/Timestamp is in particular not in the base module

Ok, I’ll see if I can figure it out, and I’ll report back if I do.

Right, that’s what’s been giving problems since IntelliJ started using JBR11 as its base JRE.

so lein's trick of adding itself to the bootclasspath doesn't work

as at boot time, only the base module is loaded

I’m pretty sure it’s not a bootclasspath issue, since this is executed within Cursive and I don’t use it.

Well, IntelliJ doesn’t use it, more accurately.

yeah, didn't make sense to me either

I run lein in an isolated classloader using shimdandy.

but it matches those symptoms

what do you put in the isolated classloader? and where is it rooted?

if it's rooted off the base loader or app loader or whatever they call it, it might only have the base module available

Yes, I think that’s probably the case. It’s rooted off the parent classloader for a boostrap class I use, which IIRC is the app classloader. It almost certainly won’t have the SQL module available.

in java 9+ that loader is represented as null (the bootstrap loader). it only has access to the base module

But my impression was that some of the older s3 wagons had problems with this that were resolved in later versions - certainly using lein, upgrading the wagon usually fixes the issue.

deps uses a newer version of the s3 wagon than the lein plugin does

But my understanding of how all this works in the brave new world is sadly incomplete. Looks like I’m going to have to figure it out.

Hmm, interesting.

well, maybe it's been updated since I last looked, not sure

Ok, I’ll see if I can reproduce the issue and debug it.