This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-03-19
Channels
- # beginners (15)
- # boot (99)
- # braid-chat (1)
- # business (1)
- # cider (109)
- # cljs-dev (1)
- # cljsrn (3)
- # clojure (249)
- # clojure-brasil (2)
- # clojure-canada (2)
- # clojure-madison (4)
- # clojure-russia (3)
- # clojure-sanfrancisco (1)
- # clojure-taiwan (1)
- # clojure-uk (1)
- # clojurebridge (1)
- # clojured (1)
- # clojurescript (15)
- # clojurewest (1)
- # cursive (9)
- # datomic (12)
- # editors (16)
- # euroclojure (1)
- # hoplon (45)
- # off-topic (22)
- # om (181)
- # onyx (2)
- # parinfer (3)
- # pedestal (17)
- # re-frame (2)
- # ring-swagger (1)
- # spacemacs (34)
- # testing (2)
- # untangled (2)
- # yada (1)
I'd like to be able to trigger a task and inspect the output. Perhaps I'm overthinking this...
@domkm: I usually do load-file on build.boot but with core/pod etc referred explicitly. Then I move it to a different file
@alandipert: I don't think I quite follow. I'd like to be able to def a task, then invoke it with a fresh fileset from the project (IDK how to create this), and then inspect the output of the task (a modified fileset, I presume).
With that said, I got this task to work so I don't need the above workflow right now, but I'd certainly like to have it figured out for future reference.
@domkm: what i meant was i'll open a boot repl
and after i modify my build.boot
i (load-file "build.boot")
in the repl. then at the repl i invoke (boot (my-task))
to see what it does
maybe what would be cool is an emacs minor mode that does (load-file "build.boot")
as an after-save action on build.boot files, if there's an active cider connection to the same project
@cfleming: i emitted some possibly weird and incoherent thoughts on the reddit thread about boot/cursive integration, very interested to hear what you think
Seems like a pretty good idea, make it the build tool’s responsibility to inform cursive/other editors.
I have a pretty good idea about how boot works, but I haven’t spent enough time seeing how most people actually use it in practice. I’ll need to actually spend some time doing that to get an idea of the best approach.
in a servlet container boot isn't the entrypoint, so there aren't pods at servlet time
I know seancorfield mentioned at some point that they have all their dependencies externalised into an EDN file - realistically I’ll never be able to support that.
so, like anyone preparing an uberwar, i need to deal with conflicts etc in the packaged jars, mergers, etc
so all the deps except expectations
makes it into the jar, because it's :scope "test"
But I’m interested in examples of funkiness, although in my experience the best way to get those examples is to release something which doesn’t support them
Yeah, I see. I still have the problem that that will only support boot projects specifically designed to be used with Cursive
not necessarily, for instance users could instrument set-env! in ther profile.boot, which is code that runs before build.boot
but yeah the static analysis maybe gets you as far as you need to go with your users, i don't know
We actually have some dependency versions in a properties file and we use that to post-process the EDN and then we sometimes we pour additional deps into that. So our dependencies are completely dynamic.
(For tooling, not for our actual programs, and that's mostly tooling we control).
So, no chance that any IDE could figure out this, short of running boot show -c
... which, funnily enough, is exactly how we bootstrap our hybrid web application.
Because then we don't have to update certain dependencies in our tool chain: we can just publish a new version of a tool and everything picks it up on the next restart.
It's also great while we're prototyping and developing new pieces (so lazy). But since we can then peg versions in a properties file later, we can override RELEASE.
but i have a sense that boot's merits make the most sense to people when it's used on a team, to define an organization's workflow
@cfleming: we keep maintaining a project.clj
and a build.boot
in tandem, just so cursive can consistently format our code 😕
i keep symlinking our build.boot
under src
and adding a (require '[boot.core :refer :all])
at the very top, so deftask
, set-env!
and task-options!
are resolvable.
but it's still not enough, because boot.core
is an implicit dependency for build.boot
, so i have to add [boot/core "2.5.5"]
to the project.clj
i generated with lein-generate
(from https://github.com/boot-clj/boot/wiki/For-Cursive-Users)
but then i have the boot version specified in 2 unconnected places: boot.properties
and project.clj
, so they can diverge 😞
@cfleming: we do love Cursive otherwise!
we - from Exicon - bought a few licenses in 2 rounds, so all of our pairing workstations are equipped with Cursive now.
thanks a lot for the great software. we learnt so much about clojure and clojure libs thanks to Cmd-Y and F1
been playing around with Boot and I like it a lot so I’m going to be using it for my next project! But one thing seems vague to me. I’m building an ring API server and most things I’ve seen with boot like pandeiro/boot-http are meant for frontend dev just to serve static contents. Is there a lein-ring style task out there or would you create your own deftask to call my own -main or handler function?
@kingoftheknoll: the server task does have a handler
option where you can pass a custom handler
in general boot task-name --help
is often a good place look for this kind of stuff
I'm writing a shebang boot script and am getting errors. The problem is that boot reports something like the following: clojure.lang.ExceptionInfo: Unable to resolve symbol: o in this context data: {:file "/tmp/boot.user5782324653526199192.clj", :line 17} java.lang.RuntimeException: Unable to resolve symbol: o in this context It's obviously a syntax error, but the larger problem is my inability to access /tmp/boot.user5782324653526199192.clj after execution ends and the reported line number in my source file contains no errors. Is there any way to remedy this? Thanks...
@inhortte: you can try using boot -b
which will print the generated boot script
@martinklepsch: How do I place options to boot in the shebang?
#!/usr/bin/env boot -b
does not work.... (and I see there are pages and pages of discussion on this at stackoverflow ).
regardless of any errors, the output is the following:
(ns boot.user (:use boot.core boot.util boot.task.built-in))
(clojure.core/comment "start boot script")
(clojure.core/comment "end boot script")
(clojure.core/let [boot?__1228__auto__ true] (clojure.core/if-not boot?__1228__auto__ (clojure.core/when-let [main__1229__auto__ (clojure.core/resolve (quote boot.user/-main))] (main__1229__auto__ "pdir_diff.clj")) (boot.core/boot "pdir_diff.clj")))
Question, once you start watching stuff you lose the repl prompt, how do you get it back?
@kingoftheknoll: I usually have a terminal boot dev
with the watch running and then connect to the REPL server
trying to do the modern-cljs tutorials, and don't really want to install Linux for this... 😞
Is there any way to compose the repl client with other tasks? I'm trying to figure out magic.
@dimovich: i'm not aware of anyone running without those errors on win7.... but i do see frequent reports that everything works great on win 10
Anyone got an example of how to handle scss compilation? After some playing around I can compile scss from src/styles to /target/public/styles. But I’m lost in how to get the produced css into the uberjar. Not even sure if the scss files should live in a source-paths dir. Realise that I sound confused. But anypointers where I can try and read up on this stuff?
@micha it's possible to include one option (or argument) meaning none if i use /usr/bin/env ...
Ok think I got the sass routine working (might just have freaked out since I had to deal with the classpath).