Clojurians Log v2

Hello - I'm looking at a legacy code base, a leiningen plugin actually, that is :aot-ing a specific dependency version. This is not a good practice, and I'd like to remove it. However, I also want to make sure that anything using my legacy code base isn't pulling in a transitive dependency, or heck even a direct dependency, that is older than the version that the plugin requires. In general I guess I'm interested in figuring out what options I have here when dealing with version conflicts.

As I understand it, the :pedantic? setting by default will warn when a version range is encountered without me having to do anything., is that right?

actually RE the above, I am a bit confused about one thing: are the dependencies of a plugin being used on a project mixed up with the dependencies on my project itself? Why is that? Would the plugin dependencies not be independent from the dependencies of the project using the plugin?

"the classpath" is my answer, nvm

@radicalmatt plugins are ran within the process of Leiningen itself (as a default). A project is ran in a separate process with its own classpath specified by its own dependencies. It doesn’t share classpath with its plugins either.

The plugin dependency tree is separate. You can actually look it via lein deps :plugin-tree

I'm working with a simple clojure 1.10 program which has a single dependecy on tools.cli. I have main.clj which contains only:

(ns foo.main
  (:require [foo.core :refer [start]])
  (:gen-class))
(defn -main [& args] (apply start args))

In project.clj, I have :main foo.main and {:aot [foo.main]}

In core.clj, I have none of the above, no type hints or reader tags. Yet I'm still seeing classfiles for foo.core in the jar products. What might be causing this?

aot compilation is transitive (it kind rides along on loading) so when you require http://foo.core it will be compiled

huh. I was wondering if that was the case, but that implies that once you :aot your -main... anything that -main then relies on is also AOT'd... and I might as well {:aot :all}?

which is understandable; it just sounds like {:aot :all} is largely implicit in the :main ... directive

Ah, apparently yes. To paraphrase the FAQ "Q: Is there a way to use an uberjar without AOT?": :uberjar, generally require AOT'ing all the things, unless you want to use clojure.main as the entrypoint and pass your main ns explicitly on the java cmdline