@superstructor: either one should work

@micha remember keybase, well look, amazing 😄 -> https://keybase.io/introducing-the-keybase-filesystem

@micha: ok thanks

@richiardiandrea: that looks pretty interesting

does it? very cool stuff from those guys 😄

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

Googling for “boot kotlin” brings up a bunch of Spring Boot stuff

i haven't seen one yet

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

I really like Kotlin

yea it looks pretty nice

That keybase filesystem looks amazing

Saw it on HN this morning.

Cbass?

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

Oh I see it now

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

boot-ubermain doesn't quite work for me

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

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

this breaks the watch function

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

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

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.

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.

@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

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)

Which PR is that?

Ah, #405

Sorry, it's issue #405

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

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

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?

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

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

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

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

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

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.

Yes good point

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.

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

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

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

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

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

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.

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

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

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

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.

There should be something like continuations for the last

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

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

Gotta go now but good idea there

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?

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

Hi Tomek.

Why, hello there.

So you were a cat all along?

Drats, could've fooled me : V

😼

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

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

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

If you use it for navigation, that is.

But maybe you should look at HTML5 history API instead?

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

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

It does for me at least.

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

@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

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

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

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

Seems like the easiest solution for end-users.

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

does boot repl initialize any ns by default?

Right, :not-found is probably better.

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

but is there anything default?

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

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

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

There is! Peridot

That would be a good start, thanks for the suggestion

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

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

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

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

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

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

OK, I haven’t done that before

but I’ll try

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

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?

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

Thanks, @pandeiro I’ll wait for your merge.

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?

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

@jstaffans: it's a maven thing afaik

http://stackoverflow.com/questions/30571/how-do-i-tell-maven-to-use-the-latest-version-of-a-dependency

apparently deprecated in mvn 3

gotcha

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

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

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

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

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

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

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

it's really hard to not break things 😞

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

hahahah

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: 

And i did download the latest binary

did you install with homebrew?

Ah that might was it

thnx

wow I can’t type

yeah somehow homebrew cache gets stale or something

Hmm still not working

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

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

It was a boot.properties file

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

@petrus: use cljsjs

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

dep: [cljsjs/moment "2.10.6-1”]

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

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

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.

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

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

"some say" that The Boot Way™ would be to serve the resource version

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

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

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

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

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

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

oh interesting. I haven’t run in to that yet. Thanks for the warning.

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

@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

@tolitius: thanks, I just used uber

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

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

@tolitius: good to hear

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

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

well that's not exactly true

the real entry point is Boot.main()

which is part of the boot.sh binary you download

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

Because I cannot find the future that is wrapping tasks execution

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

it's a java.util.concurrent.Future

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

oh ok

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

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

I am in a future

maybe

😄

each pod is associated with its own thread

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

oh wait, no that's wrong

disregard that

i'm insane

lol

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

runboot will block

unless you call it in a future or something yourself

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

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

so I am in a future somewhere

the pods that runboot get are wrapped in futures

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

that's where the future is coming from, probably

https://github.com/micha/multi-module-build/blob/master/build.boot#L30

yes I copied it with no change from there

yes then probably it's that one

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

I'll figure it out, thanks for the pointers

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

So @micha sorry to bother again, but I think I found that I am passing by https://github.com/arichiardi/boot/blob/exit-map-tests/boot/core/src/boot/core.clj#L869

through -main

so that's my future 😉

ah yes

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

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

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

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...

ah ok

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

i think we need to fix that function

the one you linked to

and anywhere else where we're derefing a future

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

yeah

that's general best practices i think

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

so basically just catch and rethrow

right

I hope I can find all those spots 😄

haha we'll find them eventually

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.

I found 14 places when grepping \(future

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

PR ^

@seancorfield thanks for your blogposts!

Happy to spread the word!

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

boot in boot in boot

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?

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

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

er.. profile.boot

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

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

yes

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

oh i see

lein in boot

😄

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?

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

install finds it in the jar itself

it should anyway

Ah, and in this case there’s no pom.xml in a random JAR.

right so you could provide one

Which I did… but had to have pom really write it to disk via target…

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

we should have been consistent and just looked in the fileset

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?

yep totally

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

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

like in your task

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

Yeah...

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

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

the whole maven design is pretty great

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

so i put all kinds of things in jars in maven

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!).

@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

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

only the lower level classpath directories are relevant there

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

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

Yeah, exactly.

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

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

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

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

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

Unless you're doing dangerous things with pods like me 😛

haha right

in that case i think you probably want the simplest model

like :directories is the real underlying thing

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

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.

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

export BOOT_EMIT_TARGET=no

in your shell configuration

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

BOOT_EMIT_TARGET=no

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

BOOT_WARN_DEPRECATED=no

it is only a warning

it shouldn't interfere with building anything

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

what is the issue you're having?

i have a task that goes like this:

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

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

for reference im using https://github.com/martinklepsch/tenzing

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

interesting..

so for example if you were doing boot production build say

you could just do boot production build show -f

nice, i'll try it

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

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

boot production show -f build show -f

so you can see before and after the build task

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

like

boot production build target