This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (50)
- # boot (82)
- # cider (42)
- # clojure (206)
- # clojure-india (1)
- # clojure-nl (2)
- # clojure-poland (2)
- # clojure-russia (1)
- # clojure-uk (6)
- # clojurescript (223)
- # code-reviews (17)
- # core-typed (3)
- # datomic (7)
- # dunaj (3)
- # editors (2)
- # instaparse (3)
- # jobs (1)
- # ldnclj (37)
- # overtone (3)
- # reactive (1)
- # reading-clojure (1)
- # reagent (24)
- # remote-jobs (1)
TBH I don’t really ‘get’ how boot does dependencies, but other dependencies seem to be working.
java.io.FileNotFoundException: Could not locate cljs/util__init.class or cljs/util.clj on classpath: when trying to require cljs namespaces
What’s unclear about how boot handles deps? Probably best to get that right first. @andrewmcveigh
Make sure to have Clojurescript with a version that supports
.cljc if you’re trying to load cljc files.
How does Leiningen load them into the repl? I think they should behave similary
I guess it took pasting that exception into this window for me to read it properly.
I think I just made a load of assumptions about how boot worked, based on the fact that it wasn’t working for me
If you have suggestions for things that could use more documentation or more prominent placement totally let people here know
I guess the thing that threw me off here is that the clojure dependency that’s set in
(set-env! :dependencies …) isn’t the one that the repl starts with.
‘cos I assumed that I must have completely misunderstood what boot was when I started reading about pods.
Probably we could add a warning if people specify clojure itself as dependency using
I guess it’s not usually that much of an issue, unless you’re trying to use cljc
@martinklepsch: so is this not correct: https://groups.google.com/d/msg/clojure/Ws2CG54vWF4/izTdgAMTYYEJ
And I had read about setting the clojure version, but it didn’t really sink in.
@ragge yes. if you use 1.6 most of the time it will just work without using
set-env! because it’s pulled in via another dependency but with 1.7 that’s not the usual case.
> Probably we could add a warning if people specify clojure itself as dependency using
To correct this: there should be a warning if the Clojure dependency in Boot’s env differs from the one specified in
@martinklepsch: sounds like a good enhancement. tbh, can't really think of a case where you'd actually want different versions, but might be missing something...
@micha: first I thought you missed my comment about the possible breakage, but then I saw the next commit
micha: was actually just about to pick up the project where i initially encountered the error
if you pass someone a stream, you don't expect them to close it unless that's agreed in some contract (docstring in the case of clojure)
in this case, you could pass a stream, a downstream functions uses it in with-open, which closes it, and when you're back in control it's already closed
tbh, i haven't looked to closely at how the merging works, maybe streams aren't the right abstraction? could you use
i'll make a little private
with-open* macro to handle the case where it's already a stream
We need a project.clj ➡️ build.boot task. Almost always the first thing I do in a newly cloned lein project just to be able to do
boot watch build-jar 😄
@alandipert: that example will get you into trouble because of sources don’t end up in jars by default w/ boot
i suspect the end game would be lein in a pod and feed it the project.clj, then inspect its runtime
altho the project.clj DSL is so broad... it's not clear if parsing directly or letting lein parse and then interpreting the lein runtime is less work
one thing we could do is run lein in a pod and have lein's target dir be a temp dir in boot