Fork me on GitHub

I had some problems calling (compile 'my-ns) from the repl. Turned out this is because the *compile-path* was set to and not a String. Does anyone know why this is? I think clojure.core should give a better error and boot should probably not set this to a (by default at least).


You will get this error:

clojure.lang.Compiler$CompilerException: java.lang.ClassCastException: cannot be cast to java.lang.String
Because this code is expecting a String
boot.user=> (class *compile-path*)
Luckily this can easily be fixed if you know this:
(defn compile-safely [ns-name]
  (let [compile-path-class *compile-path*
        corrected-path (cond
                         (instance? compile-path-class) (.getAbsolutePath *compile-path*)
                         (instance? String compile-path-class)       *compile-path*
                         (throw (ex-info "Unsupported class" {:class (class compile-path-class)})))]
    (binding [*compile-path* corrected-path]
      (compile ns-name))))


I've created a clojure issue to give a warning . I think I should create a boot issue too, but i would like to understand the rationale behind setting it to a as well


Leiningen seems to do (this) better:

➜  ~ lein repl
nREPL server started on port 61347 on host - 
REPL-y 0.3.7, nREPL 0.2.12
Clojure 1.8.0
Java HotSpot(TM) 64-Bit Server VM 1.8.0_141-b15
    Docs: (doc function-name-here)
          (find-doc "part-of-name-here")
  Source: (source function-name-here)
 Javadoc: (javadoc java-object-or-class-here)
    Exit: Control+D or (exit) or (quit)
 Results: Stored in vars *1, *2, *3, an exception in *e

user=> *compile-path*
user=> (class *compile-path*)


@alexmiller @seancorfield Thanks, the options thing worked!


Thanks @seancorfield for advice in other channel about boot-tools-deps not picking up private repo credentials in settings.xml. Is there something I can look at to determine why Boot wouldn’t be picking up that file?


You can test the theory by creating a new Boot-based project with your dependencies in regular Boot format.


I assume you verified that if you use clj with your deps.edn, the .m2/settings.xml file is picked up?


Thanks, I’ve done both of these. I will play with btd in a REPL to try and understand what’s happening.


I totally spaced on that being a new feature added to tools.deps.alpha -- good detective work!


Hey boot friends. I’ve got an internal library with a set of boot tasks for deploying and managing deployed applications. Most of the tasks take a similar set of arguments. I’d like to allow built.boot files to set defaults for these that would apply to them all, I suppose in the way that the task-options! form does, but more generally. Has anyone done something similar with boot? I can think of a couple of perhaps non-idiomatic ways to go about this, but it feels like a fairly common need, the idiomatic solution to which I may be overlooking.