metasoarous / oz

Data visualizations in Clojure and ClojureScript using Vega and Vega-lite
Eclipse Public License 1.0
828 stars 74 forks source link

Fix oz 1.6.0-alpha35 not working in leiningen #170

Closed metasoarous closed 2 years ago

metasoarous commented 2 years ago

As @mn-dimension reported here: https://github.com/metasoarous/oz/issues/168#issuecomment-937709328

I am getting the following error.

eval (current-form): (require '[oz.core :as oz])
(err) Syntax error compiling at (clojure/tools/reader/edn.clj:75:9).
(err) No such var: err/throw-no-dispatch

To replicate:

lein new test-oz

add the dependency so that the project is

(defproject test-oz "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME"
  :license {:name "EPL-2.0 OR GPL-2.0-or-later WITH Classpath-exception-2.0"
            :url "https://www.eclipse.org/legal/epl-2.0/"}
  :dependencies [[org.clojure/clojure "1.10.3"]
                 [metasoarous/oz "1.6.0-alpha35"]]
  :repl-options {:init-ns test-oz.core})
lein repl
(require '[oz.core :as oz])

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 of lein deps :tree and clj -X:deps tree to see what's getting resolved differently (you may have to do lein 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 require oz.core a second time gives this:

test-oz.core=> (require '[oz.core :as oz])
Syntax error compiling at (taoensso/encore.cljc:1:1).
namespace 'clojure.tools.reader.edn' not found

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.

metasoarous commented 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!

mn-dimension commented 2 years ago

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

metasoarous commented 2 years ago

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!

mn-dimension commented 2 years ago

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 :)

metasoarous commented 2 years ago

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!

mn-dimension commented 2 years ago

FYI - lein works with 2.0.0-alpha5 - never got to the bottom of why the other version failed !

JovanToroman commented 11 months ago

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.