Fork me on GitHub
#boot
<
2016-02-05
>
micha00:02:38

@superstructor: either one should work

micha00:02:33

@richiardiandrea: that looks pretty interesting

richiardiandrea00:02:08

does it? very cool stuff from those guys šŸ˜„

cfleming01:02:24

Am I correct in thinking that thereā€™s probably no Kotlin plugin for boot yet?

cfleming01:02:56

Googling for ā€œboot kotlinā€ brings up a bunch of Spring Boot stuff

micha01:02:01

i haven't seen one yet

micha01:02:19

i have been wanting to try it out for a while now

cfleming01:02:32

I really like Kotlin

micha01:02:01

yea it looks pretty nice

cfleming01:02:18

That keybase filesystem looks amazing

cfleming01:02:28

Saw it on HN this morning.

cfleming01:02:59

Being able to securely share files with arbitrary people from HN, Twitter or whatever is really cool

jethroksy01:02:13

Oh I see it now

richiardiandrea01:02:25

yes it is and these guys are good at what they are doing, I see they use the block chain as well for something I don't recall now

jethroksy02:02:37

boot-ubermain doesn't quite work for me

jethroksy02:02:06

pkg is just (ubermain :main-var 'tob.core/-main)

jethroksy03:02:32

also I noticed boot 2.6.0-SNAPSHOT seems to be capturing my emacs temp files i.e. .#foo.clj

jethroksy03:02:45

this breaks the watch function

seancorfield04:02:18

Ooh, I forgot that would popup messages here. I was just about to come here and ask people to test it simple_smile

seancorfield04:02:16

BTW, I did the build and deploy to Clojars from my Windows 10 laptop -- so there's another data point for Boot on Windows...

seancorfield04:02:37

I just went over the source code for boot-new and I call util/exit-error all over the place -- wherever Leiningen's new task used to call the core main abort function which prints a message and just exits the entire process with a status of 1.

seancorfield04:02:43

Throwing an exception in a task for something like argument validation seems like the wrong thing to do, if another task in the pipeline can catch that exception and suppress it.

richiardiandrea05:02:55

@seancorfield see the comment in my PR, there is also the issue that we are (potentially) running tasks in futures so the throwing of the custom App.Exit (what happens in exit-error) might not trigger things correctly

richiardiandrea05:02:10

A workaround can be to call System.exit from you last task (in my case I run in parallel, collect results then exit in the last task)

seancorfield05:02:11

Which PR is that?

richiardiandrea05:02:47

Sorry, it's issue #405

richiardiandrea05:02:57

There is an if on (instance? ) that is not correct because the exception is wrapped when thrown from inside a future

seancorfield05:02:36

Yeah, it's a harder problem than it looks on the surface. I would want to avoid requiring a change to the base Java app tho' if possible (given the discussion about the current app version supporting all full versions of Boot).

seancorfield05:02:16

So I don't think getting folks to update the Java part is really practical? Or am I missing which part you're suggesting changes?

richiardiandrea05:02:25

Yes agree, in this case the fix would be in error-ok

richiardiandrea05:02:00

But I don't know how to fix it...I need an opinion from above ;)

richiardiandrea05:02:38

To unwrap the exceptions in order to find recursively App.Exit is one option

seancorfield05:02:56

If you throw an exception in a future, it'll just get swallowed I think?

richiardiandrea05:02:49

No, from what I saw it is wrapped in ae ExecutionErception

seancorfield05:02:13

I think we probably want to separate out two use cases: argument validation executed outside the middleware part which I think should exit the whole process without a stacktrace; error conditions inside middleware for which throwing an exception is acceptable.

seancorfield05:02:16

Right now tho', a task can choose to catch (and swallow) an exception from a later task -- including argument validation -- which seems ... dangerous. I can't really put my finger on it. Just feels wrong to me.

richiardiandrea05:02:26

Well you can always swallow, the point is to provide a way to do the right thing

seancorfield05:02:44

But should a task be able to swallow argument validation errors?

richiardiandrea05:02:38

No well of course no l agree that there is something to fix

richiardiandrea05:02:09

And probably it is not a big deal either, boot's folks have already everything in place

seancorfield05:02:15

Well, the solution there is just for tasks to use (System/exit 1) for argument validation failures simple_smile

seancorfield05:02:18

I think test tasks exiting with a failure status is a grey area. I can see an argue for composability there but at the top level it looks a bit crappy.

richiardiandrea05:02:04

Mmm..Yes because at the moment there is this problem, so it is kind of unreliable, but maybe it is just a bug, so I would suspend the judgement

seancorfield05:02:30

It's tricky. There are multiple use cases here. Argument validation error feels like "exit immediately with a message and status 1".

seancorfield05:02:19

Exit OK should short-circuit execution of the task but let a pipeline continue (or let the top-level just exit cleanly with no stacktrace and status 0).

seancorfield05:02:42

Then there are two error conditions in the pipeline: a "real" exception which should print a stack trace if it hits the top-level; an "error" which should exit the task in a way that other tasks could catch and handle or the top-level would just exit with status 1 but no stack trace.

richiardiandrea05:02:47

There should be something like continuations for the last

richiardiandrea06:02:24

Yes true, and everything also unwrapped so that you try to find these "markers" nested into each other

richiardiandrea06:02:40

Please @seancorfield add this to the issue so that we don't lose it OK?

richiardiandrea06:02:56

Gotta go now but good idea there

Petrus Theron12:02:45

Any way to tell boot to do resource URL rewriting for doing dev on pushState SPAs, e.g. so that / and /my-path both serve index.html?

jaen12:02:55

You mean with boot-http? I don't think so. I suggest custom handler, at least that's what I do.

meow12:02:51

Hi Tomek.

jaen12:02:09

Why, hello there.

jaen12:02:14

So you were a cat all along?

jaen12:02:24

Drats, could've fooled me : V

meow12:02:55

šŸ˜¼

jaen12:02:03

@petrus: I do something like this https://gitlab.com/jaen/clj-cljs-presentation/blob/master/dev/dev_handler.clj which is cannibalised from the boot-http handler and modified a little to return index.html when nothing is found.

Petrus Theron12:02:56

Thanks, @jaen. The reason I need this is because bidi does not seem to support URL route prefixes like ā€œ#ā€, e.g. /#/my-route instead of /my-route

jaen12:02:57

Well, but # is hash fragment, that's something you should be dealing before you even get to bidi.

jaen12:02:08

If you use it for navigation, that is.

jaen12:02:24

But maybe you should look at HTML5 history API instead?

Petrus Theron12:02:08

Am using pushy for pushState, but the problem is that when youā€™re loading a hashless route URL without rewriting, it will 404.

jaen12:02:15

Yeah; then the handler I linked to should solve that.

jaen12:02:24

It does for me at least.

martinklepsch12:02:04

@petrus: as for bidi just add a little sanitizer that strips the #/ bit

martinklepsch12:02:45

@petrus: @jaen also there's an issue about his kind of thing in the boot-http repo: https://github.com/pandeiro/boot-http/issues/23

jaen12:02:11

Oh, nice; I've been doing that since a long time. Didn't care to report an issue, since adding a handler was easy.

pandeiro12:02:28

@jaen Yeah we were discussing whether that should be added directly to boot-http via an option...

jaen12:02:15

I'd probably be in favour of a :default-to (or similarly named) option as in my handler I linked to.

jaen12:02:26

Seems like the easiest solution for end-users.

pandeiro12:02:27

@briandunn called it :not-found but yeah :default-to is good too

dm312:02:05

does boot repl initialize any ns by default?

jaen12:02:18

Right, :not-found is probably better.

dm312:02:36

I found an :init option to boot/repl task which is pass-through to Reply

dm312:02:23

but is there anything default?

pandeiro12:02:54

OK I think I'm gonna merge that... There have been some interesting PRs for boot-http but I'm worried about including lots of options, some of which I don't use, and making sure not to break things moving forward

pandeiro12:02:41

I haven't really figured out a good testing strategy for it... That would help, too

jaen12:02:57

Maybe there is some library to create mock ring requests and see what gets returned?

pandeiro12:02:15

There is! Peridot

pandeiro12:02:36

That would be a good start, thanks for the suggestion

pandeiro12:02:08

I would also like to test the actual server integration parts though (jetty, httpkit, aleph)

jaen12:02:04

Right, but if you validate server-agnostic parts that way, you'll have less integration tests to do, hopefully.

jaen12:02:33

I almost sound as if knew how to test (but I never wrote a single test in my life).

pandeiro12:02:37

Yes I think it would be very smart to test different permutations of the default handlers and opts -- you're absolutely right, testing guru :)

Petrus Theron12:02:37

There is a boot branch on GitHub by @briandunn that adds support for a :not-found parameter on serve, but I donā€™t know how to add a boot-http dependency for a different branch (noob alert).

pandeiro12:02:17

@petrus You'd just fork that and publish yourself...

Petrus Theron12:02:27

OK, I havenā€™t done that before

Petrus Theron12:02:29

but Iā€™ll try

pandeiro12:02:41

Or... Copy the source and throw it in your source dir

wagjo12:02:43

Hey! I use a task similar to (comp (aot) (pom) (uber) (jar) (target)) and the resulting .jar has 444 permissions, instead of 644. Assuming the change was introduced by new target task, is the read-only permission intentional?

pandeiro12:02:24

@petrus I think I will merge that soon though, so there's also that

Petrus Theron12:02:47

Thanks, @pandeiro simple_smile Iā€™ll wait for your merge.

pandeiro12:02:49

Guys I remember some weirdness with cljc files and uberjars when I tested maybe ~6 months ago... Are there still any issues around cljc files with boot nowadays?

jstaffans13:02:12

is defining a dependency version with "RELEASE" a boot thing?

martinklepsch13:02:30

@jstaffans: it's a maven thing afaik

martinklepsch13:02:16

apparently deprecated in mvn 3

micha14:02:20

@wagjo: the change is related to an optimization that uses hard links instead of copying files to the target direcotry when the files are only referenced in tempdirs (so when boot ends they are essentially unreachable, so it's safe to hard link instead of copy to target dir)

micha14:02:35

you can use the --no-link option to disable this behavior

micha14:02:11

also in 2.6.0-SNAPSHOT the files in the tempdirs are no longer set to be read-only, which causes too many problems in windows to be worth the hassle

micha14:02:26

so in 2.6.0-SNAPSHOT the issue shouldn't exist at all

wagjo14:02:36

thanks! I wasn't sure whether it wasn't caused by a change in our server so I asked simple_smile

micha14:02:01

sorry about that, i hope it didn't break anything?

wagjo14:02:32

Just our deploy scripts, but I added a chmod step there and it works fine simple_smile

micha14:02:22

it's really hard to not break things šŸ˜ž

alandipert14:02:16

btw in case anyone didn't know, boot speak -t pillsbury

mitchelkuijpers15:02:37

Hi all I have a small question I am trying to hack on adzerk-oss/cljs-console but I get the following error when trying to start a repl

Downloading ...
Please download latest Boot binary: 

mitchelkuijpers15:02:48

And i did download the latest binary

micha15:02:04

did you install with homebrew?

mitchelkuijpers15:02:12

Ah that might was it

mitchelkuijpers15:02:29

wow I canā€™t type

micha15:02:51

yeah somehow homebrew cache gets stale or something

mitchelkuijpers15:02:54

Hmm still not working

micha15:02:42

perhaps which boot shows that you're using a different binary than the one downloaded by homebrew?

mitchelkuijpers15:02:42

Ī» ~/Development/cljs-console/ master which boot
/usr/local/bin/boot

mitchelkuijpers15:02:58

It was a boot.properties file

Petrus Theron15:02:44

How to do preamble with boot, e.g. to include momentJS?

Petrus Theron15:02:31

I have added that as a dep, but having a hard time referencing it.

Petrus Theron15:02:42

dep: [cljsjs/moment "2.10.6-1ā€]

martinklepsch15:02:18

if you have a (:require [cljsjs.moment]) somewhere you just reference it as if it has been added via script tag, i.e. js/moment

adamfrey15:02:39

@petrus, @jaen, @pandeiro I wrote a ring handler that have been passing to boot-http to get HTML5 history support: https://github.com/AdamFrey/ring-html5-handler, if that PR doesnā€™t get merged.

adamfrey15:02:10

as far as I know, Iā€™m the only one using it, so if you try it out and run into any problems let me know.

pandeiro15:02:17

cool @adamfrey -- just looked at the implementation, glad it works for you!

pandeiro15:02:41

one thing to keep in mind is that you're serving the file directly from "target/" there

pandeiro15:02:25

"some say" that The Boot Wayā„¢ would be to serve the resource version

jaen15:02:35

Nice; I've got my own that works well already though; might have been as smart as you though and put it somewhere accessible : V

pandeiro15:02:09

I would recommend that myself, except that there's the nasty https://github.com/pandeiro/boot-http/issues/29

adamfrey15:02:24

@pandeiro: Yeah I realized people were serving from resources after I wrote it. Iā€™ll update when I get the chance.

pandeiro15:02:44

@adamfrey One benefit of the approach you're using is that it bypasses that bug simple_smile

pandeiro15:02:35

on other words, when you have tasks in your pipeline that modify index.html, (not= (io/file "target/index.html") (io/resource "index.html"))

pandeiro15:02:00

well those wouldn't be = anyway, but their contents are not equal, either

adamfrey16:02:18

oh interesting. I havenā€™t run in to that yet. Thanks for the warning.

pandeiro16:02:26

yeah if you start to want to do things like inject analytics script snippets into your build for release, that kind of thing, you could hit that

tolitius17:02:21

@alandipert: got ubermain to work with push: https://gist.github.com/tolitius/86dded54080cd0b7527c by adding (pom) before (ubermain) which solved two things: #1 (push) sees the jar now and picks it up #2 (pom) names the file correctly, which obviates the need for --file in either (ubermain) or (push) @yenda: #2 can help you not to need :file ( adzerk-oss/boot-ubermain/pull/1) if you are waiting for it to be merged

yenda17:02:28

@tolitius: thanks, I just used uber

tolitius17:02:00

@yenda: uber did not work for me, it might have to do with collisions, i.e. how it explodes the jars..

tolitius17:02:37

but ubermain's dark side of the force does it nicely simple_smile

richiardiandrea18:02:48

A question for boot's gurus...when i do boot from cmd line, is the entry point App.runBoot ?

micha18:02:43

@richiardiandrea: the entry point is boot.App/main

micha18:02:57

well that's not exactly true

micha18:02:09

the real entry point is Boot.main()

micha18:02:22

which is part of the boot.sh binary you download

micha18:02:58

but that downloads boot.jar from github releases for the desired version of boot, and loads that in a classloader

richiardiandrea18:02:12

Because I cannot find the future that is wrapping tasks execution

micha18:02:13

that jar contains the boot.App class, which has its own main() method

micha18:02:29

it's a java.util.concurrent.Future

micha18:02:12

those are created in an ExecutorPool so boot can start all the pods at the same time

richiardiandrea18:02:21

but if I throw in a task, I am throwing inside a future right?

richiardiandrea18:02:31

oh ok wait, I think I am missing a piece, I am in a boot in boot future, that is why

richiardiandrea18:02:38

I am in a future

micha18:02:20

each pod is associated with its own thread

micha18:02:36

so if you eval expressions in there they run in a different thread

micha18:02:02

oh wait, no that's wrong

micha18:02:06

disregard that

micha18:02:09

i'm insane

richiardiandrea18:02:18

I am println-ing a lot to figure it out, I will write my findings in #405

micha18:02:44

runboot will block

micha18:02:52

unless you call it in a future or something yourself

richiardiandrea18:02:26

no I use it like this:

(comp (test-tasks pod/data commands identity) <- comp of runboot
        (helpers/parallel-start :data pod/data)
        (helpers/await-done :data pod/data)
        (helpers/test-report :data pod/data)
        (helpers/test-exit :data pod/data))

richiardiandrea18:02:02

test-exit exits with exit-error but the App.Exit is wrapped in an ExecutionException

richiardiandrea18:02:27

so I am in a future somewhere

micha18:02:37

the pods that runboot get are wrapped in futures

micha18:02:24

your implementation of runboot does it in a future, no?

micha18:02:09

that's where the future is coming from, probably

richiardiandrea18:02:25

yes I copied it with no change from there

richiardiandrea18:02:59

yes then probably it's that one

richiardiandrea18:02:44

but in runBoot usually you catch Throwable ...mmm...

richiardiandrea18:02:14

I'll figure it out, thanks for the pointers

richiardiandrea18:02:57

btw have a look at @seancorfield comment on Issue #405, very interesting ideas for exit code handling

richiardiandrea19:02:39

so that's my future šŸ˜‰

micha19:02:48

that's there because calling .invoke() on the current pod (i.e. calling invoke on a pod from within that same pod) causes errors in the clojure thread local bindings

micha19:02:10

you'll see things like pop without push errors from the clojure compiler

micha19:02:01

the solution is to run in a thread from the thread pool to avoid that problem

richiardiandrea19:02:34

ok then, I found that there is an issue when you call exit-error from inside, because the ExecutionException wraps the App.Exit effectively breaking the mechanism in exit-ok of printing/not printing the stacktrace...

richiardiandrea19:02:08

I will maybe need to add a catch branching on the fact that there is a nested App.Exit

micha19:02:28

i think we need to fix that function

micha19:02:32

the one you linked to

micha19:02:48

and anywhere else where we're derefing a future

micha19:02:13

basically derefing a future needs to have a try/catch that peels off the executionerror

micha19:02:34

that's general best practices i think

micha19:02:48

so probably should be updated anywhere we don't do it that way

richiardiandrea19:02:06

so basically just catch and rethrow

richiardiandrea19:02:27

I hope I can find all those spots šŸ˜„

micha19:02:17

haha we'll find them eventually

laforge4919:02:09

Ah, the old release and let them test it as a last recourse works so much better with open source, which is why open source is often so much better than the alternative.

richiardiandrea19:02:25

I found 14 places when grepping \(future

richiardiandrea20:02:39

@seancorfield: try now if you still have strange behaviors when exiting from tasks (`exit-ok` must not be called but I fixed a problem when exit-error is called)

drewr20:02:29

@seancorfield thanks for your blogposts!

seancorfield21:02:01

Happy to spread the word! simple_smile

dominicm21:02:58

@seancorfield: I used your boot-new to put some boot utilities in to @juxt's edge, which is built with boot.

dominicm21:02:02

boot in boot in boot

seancorfield22:02:39

given that you can do boot pom -p foo/bar -v x.y.z target install -f /path/to/some.jar -p target/META-INF/maven/foo/bar/pom.xml, does anyone think there would be value in creating a localrepo task, similar to lein-localrepo, to make this sort of thing easier?

dominicm22:02:46

I mean, could you just drop in a small task into your profile.clj?

dominicm22:02:57

I'm considering doing that for new in some way.

dominicm22:02:59

er.. profile.boot

micha22:02:27

there is also the BOOT_LOCAL_REPO setting, but it would affect downloaded deps caching too

seancorfield22:02:06

Huh? Doesnā€™t that just tell Boot to use a different folder than ~/.m2?

seancorfield22:02:27

Iā€™m talking about using lein-localrepo to install arbitrary JAR files into that local repo.

seancorfield22:02:29

So the command I typed above has a bit of duplication in it (`foo/bar`) and you have to actually write the pom.xml to target/ā€¦ it seems, because install needs a real POM file?

seancorfield22:02:09

I was a bit surprised install didnā€™t find the pom.xml in the fileset but maybe I need a sift in there?

micha22:02:26

install finds it in the jar itself

micha22:02:37

it should anyway

seancorfield22:02:40

Ah, and in this case thereā€™s no pom.xml in a random JAR.

micha22:02:52

right so you could provide one

seancorfield22:02:11

Which I didā€¦ but had to have pom really write it to disk via targetā€¦

micha22:02:37

yeah i think the tasks that have a -f option that looks in the filesystem were a bad design

micha22:02:51

we should have been consistent and just looked in the fileset

seancorfield22:02:02

So if I wrote a localrepo task, I could hide some of that, and probably tell install to use the pom.xml in the fileset instead?

micha22:02:09

yep totally

seancorfield22:02:39

Itā€™s not a big deal since I can just wrap that command in a shell script...

micha22:02:39

you could pass the path to the pom to the install task yourself

micha22:02:49

like in your task

micha22:02:02

find the path into the tempdirs and pass that with :file option

seancorfield22:02:25

Anyways, now I know how to do it, my current "itch" is scratched. I didnā€™t need lein-localrepo very oftenā€¦

seancorfield22:02:27

It means I can just as easily push arbitrary JARs to our Archiva instance via Boot which is really nice.

micha22:02:14

the whole maven design is pretty great

micha22:02:51

it has its little quirks, but overall i find it very solid and reliable

micha22:02:05

so i put all kinds of things in jars in maven simple_smile

seancorfield22:02:41

We have a few services we rely on that donā€™t publish their SDKs to Maven Central, so we put those in our Archiva repo. This was the first time Iā€™d tried to repro the lein-localrepo functionality in Boot. Very pleased it worked second time (after I added target and figured out the actual path to the generated pom.xml file!).

dominicm23:02:27

@micha is there a reason that boot distinguishes between :*-paths and then uses :directories in pods? My guess is that :*-paths lets you process filesets in different ways

micha23:02:55

@dominicm yes that is the reason, because the distinction between source and resource etc doesn't really make sense for pods

micha23:02:44

only the lower level classpath directories are relevant there

dominicm23:02:31

@micha: That's cool, just wanted to make sure. I'm trying to write a blog post on my experiences

micha23:02:36

like the pod doesn't know or care what the directories mean in the context of the build

dominicm23:02:42

Yeah, exactly.

micha23:02:20

"don't know don't care" is my favorite thing in software:)

dominicm23:02:51

I'm pretty sure that's what malcolm said when we talked about it.

dominicm23:02:03

Not that I doubted him, but I wanted to clarify it was the only reason.

micha23:02:50

the :directories key is kept in sync with the :source-paths and :resource-paths, too

micha23:02:10

so if you add to those they will be added to the :directories, too

dominicm23:02:21

Unless you're doing dangerous things with pods like me šŸ˜›

micha23:02:25

haha right

micha23:02:39

in that case i think you probably want the simplest model

micha23:02:09

like :directories is the real underlying thing

micha23:02:38

the other stuff is just extra baggage when you're doing lower level manipulations

dviramontes23:02:22

Nice boot ppl: im seeing this message at the end of every boot task i run:

Implicit target dir is deprecated, please use the target task instead.
Set BOOT_EMIT_TARGET=no to disable implicit target dir.
any ideas ??? its preventing me from compiling my cljs code..

micha23:02:55

you may do one of the following to suppress the message:

micha23:02:07

export BOOT_EMIT_TARGET=no

micha23:02:18

in your shell configuration

micha23:02:29

or add this to ~/.boot/boot.properties:

micha23:02:39

BOOT_EMIT_TARGET=no

micha23:02:08

or, if you want to use the deprecated behavior you may suppress all deprecation warnings:

micha23:02:19

BOOT_WARN_DEPRECATED=no

micha23:02:35

it is only a warning

micha23:02:44

it shouldn't interfere with building anything

dviramontes23:02:32

@micha: thanks for the prompt response. Im having issues making /target im using boot-cljs, i thought i was somehow related.

micha23:02:07

what is the issue you're having?

dviramontes23:02:15

i have a task that goes like this:

(deftask production []
  (task-options! cljs {:optimizations :advanced}
                      less   {:compression true})
  identity)

dviramontes23:02:11

and when i run it like this: boot production it fails to produce the necessary files meaning target/js etc.

micha23:02:39

a good way to debug this is to use the show -f task at the end of your pipeline

dviramontes23:02:51

interesting..

micha23:02:59

so for example if you were doing boot production build say

micha23:02:11

you could just do boot production build show -f

dviramontes23:02:22

nice, i'll try it

micha23:02:33

and that will show you a tree view of the fileset at the point in the pipeline where show -f is inserted

micha23:02:51

you could also use it multiple times to see how the fileset changes from one task to the next:

micha23:02:01

boot production show -f build show -f

micha23:02:10

so you can see before and after the build task

micha23:02:02

if you have BOOT_EMIT_TARGET=no set (which i don't think you do because you're seeing the warning) you will want to use the target task to emit files to a directory at the end of the pipeline

micha23:02:13

boot production build target