Is it necessary to reinstall from http://clojure.org to upgrade to these releases?

I tried the last tools.deps and I have a fulcro depified project that has nubank/workspaces {:mvn/version "1.0.2" :exclusions [com.cognitect/transit-java]} With the new version it does not loads transit-java. The problem is that it is excluded from workspace but its a dependency of transit-clj (of fulcro) and shadow-cljs . It looks like the exclusion is for good (affect other packages). clj -Stree does not show transit-java. When I revert to 1.9.0.397 the error is gone

Can you be more explicit with a repro to make sure I understand?

@geraldodev ^^

in particular, would love to have your full deps.edn

My deps.edn, good_tree.txt was produced with linux-install-1.9.0.397.sh bad_tree.txt was produced with linux-install-1.10.0.408.sh. Look that there are no transit-java with the latter version. It was supposed to be there because it is a dependency of fulcro and shadow-cljs

The only deps missing is a variation of sean corfield's ~/.clojure/deps.edn, but I think it does not play any role on this problem

what is the command you’re running to get the trees?

just clj -Stree ? or using any aliases?

clj -Stree on the project directory

no aliases.

The resolution appears to be different on the most recent version

thx, I will take a look

np, thnx for your work on tools.deps

@geraldodev that’s an interesting case. there are basically multiple dependency paths to transit-clj 0.8.313 (all same version). The path in which it is first found and selected (nubank/workspaces -> com.cognitect/transit-clj) happens to exclude its transitive dep, com.cognitect/transit-java.

I checked the version. It was strange to me because it is the same like you saw

in simplest form:

tree:
  A (excl C) -> B -> C
  D -> B -> C
selected:
  A, D, B

whereas if B happened to be encountered via D first, C would be included

I know why what you’re seeing happened to change, but I think this problem likely existed on the prior version too, but via some other arbitrary ordering

I will need to think about this a bit

But you are ble to get transit-java on prior version

you happened to get transit-java on prior version

via arbitrary ordering. I get it. It's a coincidence...

but I don’t actually think you’re guaranteed that - it’s probably a result of the order the deps are being encountered

I’m not certain of that, but that’s my suspicion

I think what this dependency tree is saying is not self-consistent

that is, if you treated the deps as logical propositions, there is no solution that satisfies both excluding C under A and including it under D in that simple version above

given that it’s the same B in both cases

for example, if you run this same example in Maven, you get a match of the “bad” tree (no transit-java included at all)

Wouldn't you want it to be like:

tree:
  A1 (excl C1) -> B1 -> C1
  D2 -> B2 -> C2
selected:
  A1, D2, (resolve-duplicate #{B1 B2}), C2

in this particular case, the versions of B and C in both branches are identical

so I omitted the versions

if the two B’s are identical, then it shouldn’t matter which one you choose

and exclusions are never version-specific

There are no explicity dependency of transit-java on lein's fulcro template. It appears to include it.

tree:
  A1 (excl C) -> B1 -> C1
  D1 -> B1 -> C1
selected:
  A1, D1, B1

is a version-specific example (and the exclusion intentionally does not have a version, as exclusions are not version-specific)

I guess I was thinking the semantics of exclusion were more "omit C from the entire transitive tree of A", not "globally exclude C from the tree"

it is the former

but I’m saying that omit C1 can’t be consistent with also saying include D1 which depends on B1 which depends on C1

you’re saying both omit C1 and include C1 - we can’t do both

I see the contradiction, yeah...

I guess I'd just intuitively expect that in order to get the behavior where C is excluded, you'd have to do

tree:
  A1 (excl C) -> B1 -> C1
  D1 (excl C) -> B1 -> C1
selected:
  A1, D1, B1

yes, that is what you have to do in either clj or Maven

there have been requests for global exclusions as a feature but that’s not currently a thing

if anything were to be done on this, it would be to make it non-arbitrary

bascially if you have B and B (excl C), do not treat those as interchangeable - prefer one over the other

this gets tricky when combined with version comparisons though

and I’m not sure which one you would want to prefer

seems like geraldodev’s expectation is that you would prefer including it

yes, like lein does

lein relies on Maven’s selection, which is also order-dependent

it wouldn’t surprise me if the ordering affected what you got in lein too

if workspace is not picking a version for you and another package is so be it. because it needs to be there. the version being the same is irrelevant to a greater proposal of having the lib

this is not about version picking though, it’s about inclusion vs exclusion

but the exclusion was caused because of the version being the same

there is no set of dependencies that can satisfy the constraints stated, so the most correct answer here is actually to fail

we’re just pouring semantics over the top of a logically inconsistent case

we do that all the time when selecting deps though wrt versions

the question is kind of, are exclusions global, or are exclusions local. are exclusions applied while determining what the transitive dependencies of a given dependency are, or are they applied later after all the dependencies have been determined an a graph has been created

that’s not the question

exclusions are not global

they are always contextual

lein deps :tree on template project after lein ancient :upgrade. It uses workspaces on 1.0.2

the selection algorithm is attempting to satisfy (often contradictory) constraints while also balancing performance concerns

transit-java is being picked by transitive dependency of shadow-cljs

clj is intentionally not using the same algorithm as either lein or Maven

those both prefer versions that are closer to the top or first encountered at a sibling level

clj prefers the newest

maybe I misstated it, but it sounds like the difference between the current observed behavior, and the behavior @geraldodev is suggesting is between applying exclusions before or after it has been determined that the B both A and D depend on is the same, which maybe isn't possible, but I described it as global because it seems like in order to know A and D depend on the same B you need a global view of the dependency graph

@alexmiller it's the newest and forbbidenn by one dependency

I think this discussion is missing too much context of what’s being considered to be correct

like when choosing versions, you have to consider what versions you’ve seen, whether a version is under an exclusion of a selected version, etc

@alexmiller I'm in no place to argue about this. I just expected the lein behaviour.

and for performance reasons, we’re doing this in one pass, which limits information and when you know things

I’m still contending that the overall dependency tree here is logically inconsistent and there is no solution that meets all constraints

I would not be surprised if lein / Maven both have order-dependent answers to this and depending how you order things, you could see transit-java either being included or not here

if that’s not true, then their selection algorithm is effectively placing some preference, either intentionally or accidentally

clj’s selection algorithm is different, and may or may not make the same choice

I would prefer it not to be order-dependent though as that’s generally a source of confusion

Maven’s algorithm relies on order as means of selection, so it has to be

some of it is maybe ergonomic, having the exclusion listed on a particular dependency leads to the expectation (as incorrect as it may be) that the exclusion is somehow limited in scope to that dependency and won't effect dependency info from other deps

In order to use Neanderthal on a Mac you need to specify these exclusions: https://github.com/uncomplicate/neanderthal/blob/7cf295119527843a6d1e9c17161b8a7b2f741309/examples/hello-world/project.clj#L6-L7. I cannot figure out a way to do this in a deps.edn. I tried this:

{:deps {uncomplicate/neanderthal {:mvn/version "0.19.0"
                                  :exclusions  [[org.jcuda/jcuda-natives :classifier "apple-x86_64"]
                                                [org.jcuda/jcublas-natives :classifier "apple-x86_64"]]}}}

Error building classpath. Could not find artifact org.jcuda:jcuda-natives:jar:apple-x86_64:0.9.0 in central ()

{:deps {uncomplicate/neanderthal {:mvn/version "0.19.0"
                                  :exclusions  [org.jcuda/jcuda-natives org.jcuda/jcublas-natives]}}}

exclusions in Maven can’t use classifiers afaik (certainly the deps.edn version does not support it)

I would expect something like this to work

{:deps {uncomplicate/neanderthal {:mvn/version "0.19.0" :exclusions [org.jcuda/jcuda-natives org.jcuda/jcublas-natives]}}}

That results in

Error building classpath. Could not find artifact org.jcuda:jcuda-natives:jar:apple-x86_64:0.9.0 in central ()

Having the exclusions that are in project.clj works as expected.

… in a project.clj.

yeah, the error there is accurate - there is no such jar

I guess this could be the exclusion code not being classifier aware

so it doesn’t know to try to exclude the os-dependent dependency

could I trouble you to file a ticket at https://dev.clojure.org/jira/browse/TDEPS ?

assuming that’s the issue, it shouldn’t be hard to fix

yeah, that was it. I have a fix for it

Great! Should I still file a ticket?

yes please

or I can do it if you want

Ok will do in a bit. Is there a workaround for now?

I am getting this error when using clojure on a different computer than my usual one.

Error resolving /Users/Mark1/Provisdom/math: [email protected]:...: USERAUTH fail
Cloning: [email protected]:...

It uses jgit, so is a different pile of stuff

Can’t say I have enough to go on there

What os? Ssh?

Private or public repo?

Mac OS. SSH. Public.