Clojurians Log v2

I had some problems calling (compile 'my-ns) from the repl. Turned out this is because the *compile-path* was set to java.io.File 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 java.io.File (by default at least).

You will get this error:

clojure.lang.Compiler$CompilerException: java.lang.ClassCastException: java.io.File cannot be cast to java.lang.String

boot.user=> (class *compile-path*)
java.io.File

(defn compile-safely [ns-name]
  (let [compile-path-class *compile-path*
        corrected-path (cond
                         (instance? java.io.File compile-path-class) (.getAbsolutePath *compile-path*)
                         (instance? String compile-path-class)       *compile-path*
                         :else
                         (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 https://dev.clojure.org/jira/browse/CLJ-2412 . I think I should create a boot issue too, but i would like to understand the rationale behind setting it to a java.io.File as well

Leiningen seems to do (this) better:

➜  ~ lein repl
nREPL server started on port 61347 on host 127.0.0.1 - <nrepl://127.0.0.1:61347>
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=&gt; *compile-path*
"target/classes"
user=&gt; (class *compile-path*)
java.lang.String

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

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.