Closed metasoarous closed 2 years ago
I don't have time to look at this in greater depth right now @mn-dimension, but can try to get around to it next week. Please feel free to investigate further yourself if you're able, and I can cut a new release for you if you sort out what versions need to get updated here (though it may be that a third party lib needs to update their dependencies).
Thanks in advance!
Hi - I think you are right regarding the dependencies. This only started to happen after you recently updated them. I too am a bit stuck for time at the moment but will take a look when I can.
Cheers
I still don't know exactly what caused this to fail with lein
while working with clj
& deps.edn
, since it seems like both should have resolved the same, but :shrug:
In any case, I updated tools.reader
to the latest, and that fixed this (see 1560d41). Using metasoarous/oz "1.6.0-alpha36"
in lein now works for me.
Thanks again for pointing this out!
Thanks. I will give it a go and let you know.
I'm not sure either but I do know the dependency tree created by lein and clj/deps.edn are created differently. Lein is order dependent in the project file and clj/deps.edn takes the "latest" version. I think it will be something to do with this.
At some point I will move over from lein. tp clj tools :)
Thanks. I will give it a go and let you know.
Wonderful; Thank you!
I'm not sure either but I do know the dependency tree created by lein and clj/deps.edn are created differently. Lein is order dependent in the project file and clj/deps.edn takes the "latest" version.
Yeah; I'm aware that they're different (though I'll point out that clj/deps.edn places highest priority based on proximity to "root" in the dependency tree, and only takes the "latest" version if there's a tie). What surprises me here is that if you are using a bare bones project.clj
with no dependencies but clojure and Oz, for the Oz dependencies, it has to just use the resolution that clj spits out in the pom.xml. Lein can't be looking at order in a :dependencies
vector, because there is no such vector for Oz. So if there aren't any other dependencies in the project.clj
that use tools.reader
, then where is the conflict and different resolution coming from?
At some point I will move over from lein. tp clj tools :)
I really can't recommend it enough. I was more or less happy with lein back when that was the only tool around (till boot, which always seemed like a pretty specialized tool), especially in comparison with the tooling shitshow endemic to a lot of other langs. But clj/deps.edn really hit the nail square on the head in so many ways, and this dependency resolution business is a prime example of that. In retrospect, vector order resolution was always just a bonkers idea. It also really got things like aliases right, which have solved a whole host of problems, and made a lot of neat things possible.
Anyway; Thanks again, and good luck!
FYI - lein works with 2.0.0-alpha5
- never got to the bottom of why the other version failed !
For me it was the tools.reader
dep. when moving to a newer Datomic version. I updated it to the latest v. and the problem disappeared.
As @mn-dimension reported here: https://github.com/metasoarous/oz/issues/168#issuecomment-937709328
After trying these versions of Clojure and oz out in the
clj
tooling, I was not able to reproduce this error. This has me thinking that this is a result of differences in the way clj tooling and lein resolve dependencies.My suggestion for solving this issue (aside from moving to
clj
, which I've been much happier with), is to have a detailed look at the output oflein deps :tree
andclj -X:deps tree
to see what's getting resolved differently (you may have to dolein pom && mvn dependency:tree -Dverbose=true
to get the complete tree out of lein, if this ends up being another AOT compilation issue).I have a hunch that the issue may be in
taoensso/encore
, since attempting to requireoz.core
a second time gives this:However, it could be another library is AOT compiled against this version, which is causing the issues in encore. If I had to wager a hunch, I'd look at
clojupyter
, since it tends to be behind a lot of these issues. But looking through the deps as described above should lead to the error.