This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-06-19
Channels
- # 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)
Hi, I’m having issues with boot & cljs deps.
TBH I don’t really ‘get’ how boot does dependencies, but other dependencies seem to be working.
I get java.io.FileNotFoundException: Could not locate cljs/util__init.class or cljs/util.clj on classpath:
when trying to require cljs namespaces
Ah… maybe this is .cljc related?
What’s unclear about how boot handles deps? Probably best to get that right first. @andrewmcveigh
Well, I guess the fact that it doesn’t load them into the repl like leiningen.
Make sure to have Clojurescript with a version that supports .cljc
if you’re trying to load cljc files.
But, I’ve fixed the issue.
I didn’t have boot on the right clojure version.
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.
Whatever floats your boat
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.
Followed by pods
‘cos I assumed that I must have completely misunderstood what boot was when I started reading about pods.
Did you read the wiki pages?
Probably we could add a warning if people specify clojure itself as dependency using set-env!
?
Yeah, but I possibly started in the wrong place.
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.
@martinklepsch: the need to set clojure version both in properties and and env?
@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 set-env!
?
To correct this: there should be a warning if the Clojure dependency in Boot’s env differs from the one specified in boot.properties
@martinklepsch: Yes, I think this ^^ would have helped
@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...
I’m not sure if different versions would work at all. 😛
@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 File
instead?
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
Probably quite hard to support things beside minimal library projects
one thing we could do is run lein in a pod and have lein's target dir be a temp dir in boot
Loading things at runtime — how again? 😕
No luck with (resolve #’bootlaces!)
got it.
sweet! a nice addition to any profile.boot