This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-10-04
Channels
- # 100-days-of-code (8)
- # announcements (4)
- # beginners (77)
- # boot (11)
- # business (13)
- # cider (69)
- # clara (2)
- # cljdoc (51)
- # clojure (59)
- # clojure-dev (18)
- # clojure-italy (4)
- # clojure-nl (11)
- # clojure-spec (54)
- # clojure-uk (115)
- # clojurescript (33)
- # core-async (4)
- # cursive (95)
- # datomic (27)
- # duct (1)
- # emacs (58)
- # figwheel (22)
- # figwheel-main (63)
- # garden (1)
- # graphql (10)
- # hyperfiddle (1)
- # leiningen (1)
- # luminus (6)
- # off-topic (12)
- # planck (7)
- # portkey (1)
- # quil (3)
- # re-frame (3)
- # reagent (5)
- # ring-swagger (3)
- # shadow-cljs (34)
- # slack-help (19)
- # spacemacs (57)
- # testing (2)
- # timbre (2)
- # tools-deps (42)
- # yada (6)
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
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))))
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 -
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
@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.