Fork me on GitHub
#leiningen
<
2020-05-24
>
radicalmatt18: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?

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

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?

alexmiller21:05:59

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

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