tools-deps 2021-07-24 | Slack Archive

souenzzo17:07:15

Hey I'm having a wired exception. It is probably something with localstate, like removing .m2 .gitlibs should fix it But it's a crypt exception, I think that we can try to understand and improve this error message. At least, know which file cause this exception https://gist.github.com/souenzzo/7ab1a37ad172efef71a6765b13413704

seancorfield17:07:24

@souenzzo My first thought was that it might be a version conflict on org.clojure/data.xml in your environment, since it says that a Var in that lib isn't defined -- but when I looked at blame on clojure.data.xml that element-nss has been in there for six years at this point so that theory doesn't seem terribly likely.

seancorfield17:07:26

Did you succeed in making the error go away? Can you reproduce it?

seancorfield17:07:15

Could there be an 0.0.8 version of data.xml in your transitive dependencies? That didn't have those Vars (but it didn't have some of the same namespaces at all).

souenzzo19:07:31

(some #{"/home/souenzzo/.m2/repository/org/clojure/data.xml/0.2.0-alpha6/data.xml-0.2.0-alpha6.jar"}
  (string/split (System/getProperty "java.class.path")
    #":"))
=> "/home/souenzzo/.m2/repository/org/clojure/data.xml/0.2.0-alpha6/data.xml-0.2.0-alpha6.jar"

souenzzo19:07:03

It's something with the fact of tools.build being in my classpath

seancorfield20:07:32

Yeah, having tools.build be "in addition" instead of "replacing" can lead to some problematic situations, but mostly around tools.deps.alpha in our experience.

seancorfield20:07:33

That's why we run tests in a subprocess and avoid having our code on the classpath when using tools.build.

seancorfield20:07:00

I'd have to see more of your deps.edn file and how you're invoking the build script to be able to provide any more specific feedback, I suspect.

seancorfield20:07:02

@jgomo3 Saw your post on ClojureVerse -- if you hop into #tools-deps here, you can get more "real-time" assistance on tools.build etc.

greg23:07:43

@seancorfield I've seen today one of your talks from the Jan this year about REPL development. It included demoing of Reveal and add-libs. The idea of adding libs in a runtime is so nice, but I've got a question. How do you deal with adding newer version of libs? Or loading a fork? Today I had this issue that I loaded a lib from github, then I forked it, modified it, updated deps with my fork, called add-libs on updated deps, but at the end, I still had the old version at hand. Also, when I checked (:libs (clojure.tools.deps.alpha.repl/current-basis)) it still contained the info about the old dep. At the end I had to restart REPL as usual, but it would be nice to keep it on if possible. How do you tackle this kind of issue?

seancorfield23:07:43

You can't add a newer version of a library you have already loaded, without starting a new isolated Clojure instance (which you can do without restarting the JVM but it's non-trivial). If I'm iterating on a library locally for which I have the source, I just use "load file" in my editor and eval every form I change -- that will override any previously loaded (older) version, just like evaluating any other source code.

seancorfield23:07:27

I don't find I need to update libraries all that often while I'm actually developing.

greg23:07:32

Ok, that is actually not the bad idea. The IDE can fetch new deps, and then you can reload necessary files.

seancorfield23:07:31

It feels like it's taken me a long time to settle on a nice workflow in the REPL. I'm very productive with it now and my REPLs all tend to be long-lived at this point (often weeks, sometimes months).

2021-07-24

Channels