Fork me on GitHub
#boot
<
2017-02-19
>
richiardiandrea00:02:20

Yes that makes it interesting

fossifoo08:02:14

i think i don't get boot-cljs

fossifoo08:02:31

so far i used boot-http, but i want to precompile for production

fossifoo08:02:25

i can't even figure out how to call it in a way that would just put the files in some dir

fossifoo08:02:31

ah, i found out about the "target" task

fossifoo09:02:30

oh, "nice" setting target to "." deletes just everything 😞

fossifoo09:02:55

i just wanted the project.jar in .

fossifoo09:02:04

well, i got that

qqq09:02:32

imho, when target is set to ".", boot should (1) ignore the command and (2) display a warning in BIG RED LETTERS

qqq09:02:48

I can't think of a single situation where someone intentionsly wants to nuke build.boot and src/

martinklepsch09:02:02

@qqq agree, would you like to come up with a PR?

qqq09:02:45

You mean I need to do actual work instead of getting other people to do work? 🙂

qqq09:02:46

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)

fossifoo09:02:46

well, it would at least help if that would be more obvious from the docs

fossifoo09:02:05

yes, it says it on the 3rd paragraph somewhere in the wiki

martinklepsch09:02:09

@fossifoo I think most people just invoke target without options which will dump files in target/

fossifoo09:02:28

i "just" changed it for my uber-jar build

fossifoo09:02:41

because i wanted the project.jar to go into another thing

fossifoo09:02:46

not along my cljs build

fossifoo09:02:53

so i figured "." would be fine for now

martinklepsch09:02:59

(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)

fossifoo09:02:08

then i ran it and all i was left was project.jar 😄

qqq09:02:11

@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)

martinklepsch09:02:29

@qqq yeah, not complaining about that/or saying it’s wrong

fossifoo09:02:12

it's kinda logical from how boot works

fossifoo09:02:39

but building "seperate" things in the same project is kinda weird with boot

fossifoo09:02:55

especially since there aren't so many examples for now

fossifoo09:02:27

i used tenzing and just need gzip compression, so taking on a jetty/ring server is already much harder than i imagined

fossifoo09:02:51

maybe it's also a point to document that there along with the "no backend" section

fossifoo09:02:11

like: if you want to add a server later, and not use boot-http in production, here's how

fossifoo09:02:35

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

qqq09:02:29

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

mobileink19:02:41

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.

mobileink19:02:15

if you mash everything into one project you'll

mobileink19:02:05

have a much harder time assigning FE and BE to different people.

mobileink19:02:47

with boot checkouts and watch tasks, you can integrate testing while keeping component development sequestered.

fossifoo09:02:43

well, the other is not better either

qqq09:02:59

currently, I'm a big fan of separate projects for client/server

fossifoo09:02:01

because after all is done, i need my javascript in some docker image along with the jar

qqq09:02:16

are you doing GAE/AWS by any chance?

fossifoo09:02:23

i've done this with symlinks and also git submodules, but it's also weird

qqq09:02:55

google compute engine?

qqq09:02:06

join us over at #google-cloud 🙂

fossifoo09:02:14

container, but yeah, it's kubernetes on top of GCE

bhagany14:02:01

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?