Fork me on GitHub
#boot
<
2018-10-04
>
jeroenvandijk08:10:13

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

jeroenvandijk08:10:47

You will get this error:

clojure.lang.Compiler$CompilerException: java.lang.ClassCastException: java.io.File cannot be cast to java.lang.String
Because this code https://github.com/clojure/clojure/blob/clojure-1.9.0/src/jvm/clojure/lang/Compiler.java#L7538 is expecting a String
boot.user=> (class *compile-path*)
java.io.File
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? 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))))

jeroenvandijk08:10:19

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

jeroenvandijk10:10:13

Leiningen seems to do (this) better:

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

samedhi15:10:11

@alexmiller @seancorfield Thanks, the options thing worked!

Chris17:10:49

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?

seancorfield17:10:33

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

seancorfield17:10:20

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

Chris08:10:37

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

seancorfield16:10:19

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

donaldball18:10:44

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.