venantius / ultra

A Leiningen plugin for a superior development environment
Eclipse Public License 1.0
1.24k stars 37 forks source link

Do not fail if a non-string version found for Clojure artifact #69

Closed dm3 closed 6 years ago

dm3 commented 7 years ago

Another issue when using lein-modules - the version is sometimes provided as a an underscore (symbol).

venantius commented 7 years ago

Can you give me an example of a valid project.clj so that I can understand this?

dm3 commented 7 years ago

We have a parent project.clj defined similar to this:

(defproject some/parent "0.1.0-SNAPSHOT"
  :packaging "pom"
  :plugins [[lein-modules "0.3.11"]]
  :profiles {:provided {:dependencies [[org.clojure/clojure _]]}}
  :modules {:inherited {}
            :versions {org.clojure/clojure "1.9.0-alpha13"}})

given the above, Ultra gets the :dependencies element of the project.clj for a module project which looks like this:

([org.clojure/clojure _ :scope "provided"]
 [org.clojure/tools.nrepl "0.2.10" :exclusions ([org.clojure/clojure])]
 [clojure-complete/clojure-complete
  "0.2.3"
  :exclusions
  ([org.clojure/clojure])])

Having thought about it, it's probably better to actually find the non-placeholder version in the project map. However, it doesn't hurt to at least not fail on the above case.

venantius commented 7 years ago

Yeah, I don't think the current proposal is ideal. What we want to do is to identify the actual version in the project map that'll be used. I'd say we probably want to explicitly ignore cases in which we use "_" (and from the lein-modules docs, you should be using a string there, not a symbol), and then figure out where the actual clojure.core version is coming from and check against that.

dm3 commented 7 years ago

Agree with that. However, it seems OK to assume a version of Clojure if we're unable to figure it out instead of failing.

I'm not sure if I'll have the time to investigate this properly as I'm mainly using Boot. Thanks for the great plugin anyway!