This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-19
Channels
- # beginners (7)
- # boot (48)
- # clojure (50)
- # clojure-portugal (1)
- # clojure-russia (10)
- # clojure-spec (29)
- # clojure-uk (9)
- # clojurescript (116)
- # core-logic (1)
- # cursive (12)
- # datascript (2)
- # datomic (7)
- # defnpodcast (8)
- # dirac (80)
- # emacs (486)
- # hoplon (5)
- # instaparse (3)
- # keechma (1)
- # luminus (3)
- # lumo (35)
- # off-topic (65)
- # om (6)
- # onyx (6)
- # perun (42)
- # re-frame (5)
- # reagent (5)
- # rum (2)
- # untangled (170)
- # vim (13)
Yes that makes it interesting
i can't even figure out how to call it in a way that would just put the files in some dir
imho, when target is set to ".", boot should (1) ignore the command and (2) display a warning in BIG RED LETTERS
I can't think of a single situation where someone intentionsly wants to nuke build.boot and src/
@qqq agree, would you like to come up with a PR?
@fossifoo sorry about that
I'm actually completely unfamiliar with the boot source code. But I suspect for someone who does understand it, it's probably possible to do a (== ".") check, or count the number of "../" 's and if it's greater than the number of "down movements", then ignore it (i.e. lands at parent directory)
A good first step could be checking (= dir “.”)
around here: https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/task/built_in.clj#L381
@fossifoo I think most people just invoke target
without options which will dump files in target/
(initially that task didn’t even have an option to specify a different dir IIRC, that might be part of the reason why documentation doesn’t mention it clearly)
@martinklepsch : I think @fossifoo 's argument is: if you're seeing (target ...) for the first time, and do NOT know apriori that the default value is "target/", then "." is a perfectly valid value (thinking that it's the dir where the "target" dir goes into)
@qqq yeah, not complaining about that/or saying it’s wrong
i used tenzing and just need gzip compression, so taking on a jetty/ring server is already much harder than i imagined
like: if you want to add a server later, and not use boot-http in production, here's how
from lein and about all other build tools i'm simply used to say: this task goes into "target" and then call the build tool again and produce another thing in target as well
in my (very limited) experience with clj/cljs on server/client, I found "having a single project for both parts" is great on paper, but horrific in practice
qqq: @fossifoo fwiw i use three projects: one for FE, one for BE, one to compose them. FE and BE are just component libs in the app.
with boot checkouts and watch tasks, you can integrate testing while keeping component development sequestered.
because after all is done, i need my javascript in some docker image along with the jar
I'm looking for input on whether records are supported as input to a pod (context: https://github.com/hashobject/perun/issues/171). Records don't work naively with boot.pod/with-call-in
because deserialization happens before with-call-in
requires any namespaces. However, if that namespace is required beforehand (for example by using boot.pod/require-in
), the record is deserialized without problems. The confusion about whether it's supported stems from the docs for require-in
(https://github.com/boot-clj/boot/blob/master/doc/boot.pod.md#require-in) that suggest this should be avoided. Is there an official stance on this?