Fork me on GitHub
#leiningen
<
2020-05-24
>
mister_m18:05:44

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?

mister_m19:05:10

"the classpath" is my answer, nvm

mikerod20:05:24

@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.

mikerod20:05:15

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

👍 4
penryu21:05:20

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

penryu21:05:02

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

penryu21:05:53

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?

Alex Miller (Clojure team)21:05:59

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

thanks3 4
penryu22:05:55

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}?

penryu22:05:15

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

penryu22:05:50

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

👍 4