This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (6)
- # announcements (1)
- # beginners (1)
- # boot (104)
- # braid-chat (5)
- # cbus (1)
- # cider (2)
- # clojure (147)
- # clojure-japan (1)
- # clojure-poland (1)
- # clojure-russia (31)
- # clojurescript (16)
- # core-async (4)
- # css (2)
- # cursive (14)
- # datomic (40)
- # devcards (5)
- # dirac (100)
- # emacs (5)
- # funcool (1)
- # immutant (52)
- # juxt (4)
- # ldnclj (128)
- # lein-figwheel (12)
- # leiningen (26)
- # luminus (3)
- # mount (22)
- # off-topic (11)
- # om (144)
- # onyx (2)
- # parinfer (1)
- # proton (7)
- # re-frame (55)
- # reagent (16)
- # slack-help (5)
- # yada (1)
@hlolli: i was just asking a similar question the other day.
i notice that on some of the major devcards doc pages they even mentioned
boot-reload as an alternative solution if u don't want figwheel
dev-resources that I'd like to be added to resources when repl starts. don't want for it to be included in the build of course. is there a way to do that besides creating a new task i.e. "dev" that would set things up and call a repl?
rather a simple question, I always used a
dev task before, and never needed
boot repl to also know about my dev resources. but I just want to understand it a bit better, overriding
boot.task.built-in/repl feels very uncouth
I can definitely wrap those in a
.sh but it is a bit involved for a simple thing like this
I see, thanks. how do you guys do it, do you not need those resources when you just run
ok.. I see, so I am not "one off", I thought this is just something I use, and don't know how to
boot repl correctly
@micha I arrived to this from the fact that I could not couple test resources under test, i.e.
test code resources
i've only just begun to appreciate the beauty of the CLI pipeline - makes it easy to customize builds on-the-fly
@mobileink: good read about cider-repl, thanks. I use vi, but still the fact that all can be customized and programmed is great
regarding dev-only resources: boot makes it possible not only to do that, but have dev-only build structures! very very cool. - i'm finishing up a rewrite of boot-gae that allows you to build and test with or without servlets, filters, security, etc. i don't even want to think about how to do that without filesets.
so e.g. if you just want to test a single servlet using a subset of your resources, you just select the right subset of build tasks and the output has only the stuff you asked for
@mobileink: sounds very cursor'ish, not in a bad way is
boot-gae a new boot google app engine thing that is coming up soon?
yep. you can take a look at it and start experimenting but the README for the tasklib is a little out of date - you'll need to look at the build.boot and .edn config files in the test app to see what's happening. it's at https://github.com/migae/boot-gae
@micha, @alandipert : FYI I've redesigned
boot-gae along the lines you recommended. if you find a chance to take a look i'd be interested in your feedback. i broke the tasks down into smaller ones, and followed the example of
boot-reload in using
.edn config files. But with a little bit of a difference: i realized you can pass a master .edn config file through the pipeline, and different tasks can "elaborate" it using their own task-specific
.edn files. then only at the end is there a task that takes the master config file and uses it to generate stuff. that was a real revelation! it makes it possible to split the construction of one monolithic output - e.g. web.xml - into multiple independent tasks, so you can easily include/omit whatever you want at dev/prod time.
for example, you want to use a "reload" filter at dev time to get reload-on-refresh, but you don't want that in production. previously I always had to manually fiddle with config files to handle this - with boot its just controlled by a
reloader tasks - you want the filter, run that task; you don't, don't run it.
Hmm, I returned to using boot-cljs-repl after usign dirac (can't use it with PhoneGap/Cordova) and I'm getting this: https://gist.github.com/jaen/0bf18ac8a83cd6d57727 Any idea what I should be looking at to figure out what's wrong?
Ok, when I remove dirac from my dependencies I still get the error, but REPL at least works, so that's probably just some dependency problem, sorry
anybody here understand gradle sourcesets? I've been dealing with gradle for a couple years (android, gae) but still do not understand them. I go out of my way to avoid actually having to learn how gradle works. strangely, I tend to go out of my way to understand how boot works. I'd like to contrast sourcesets with filesets but that's hard to do when you don't know what they are.
FWIW I suspect sourcesets are perfume on a turd, they don't really solve any problem, they just move it. whereas filesets are areal solution.
I get the impression that gradle thinks of sourcesets in a way that is similar to the way one might think of filesets. but they're not first class, they're just a complicated way of collecting strings, in a way.
ah, yes! filesets sever the link between fname and on-disk fcontent (by snapshotting).
I'm looking at the android gradle plugin. lots of sourcesets and other cruft. I think boot could do flavors etc. in a much more simple and trad parent manner.
e.g. demo v. full. in contrast to "build types", e.g. debug v. release. they also add "flavor dimension", e.g. x86 v. arm v. mips.
question for the core devs: did you consciously reject the idea of including task dependencies as part of taking defns? when I started with boot that struck me as strange and suspicious for a build tool. now I think it was a wise decision.
it's one thing to say a task depends on a thing; it's an entirely different thing to say it depends on another task.
@mobileink about flavors, I implemented them with an
options multimethod that dispatches on a vector
[flavor build-type]. Very easy with boot.
like we found that it's trivial for the user to know which order the pipeline should be, but extremely difficult for the computer to figure it out from annotations etc
i guess that's the philosophy behind everything in there, the user knows what they want to do way better than the tool can know
and lisp provides the means to abstract over any parts that involve boilerplate or tedium
there was a tricky part in handling
boot runtime deps so you can see that at line
because the runtime needs the correct deps with
set-env! and you cannot change them after that (@micha of course better knows the details and explained me what to do)
make sense actually, it needs it for the
boot process to work, then in the task I can customize them further
set-env! effectively change them for the subsequent tasks: https://gist.github.com/arichiardi/d6b98614835039adec59#file-build-clj-L159
I can tell that because the
[:backend :prod] final uberjar does not contain
anyways it was fun to implement and I could still get what I wanted, which is awesome 😄
another flavor can be easily added as it is just an additional multimethod, like
(defmethod options [:frontend-ie :prod] [selection] ...)
how would I say "build the debug version of the demo version"? I see the -t option for :devel but where's the option for demo?
the idea that came to me is you have demo.build in BUILD_FILE, so you just do
boot debug with that.
but it is up to you, I just wanted to show you the power of having a language at your disposal in your build file, but you know that already 😄
no, boot is beyond awesome. ;) I'll definitely take a good look at your code, thanks for sharing it!
I feel like I have not heaped sufficient praise on the devs for at least a day. you guys are geniuses! Here's a slogan for you: "Boot: Clojure's killer app." At long last.
(the word you're looking for is "complex", or maybe "complicated".) sorry, crusty old fart here.
haha. Genius? absolutely. Feet of clay? well yes. my nightmare is I'm having a beer with RH and he says "complected" and I go berserk and suddenly all my clojure code steps wroking. such is the fate of liberal arts grads in today's world.