I might be missing something, but is there a way to halt/abort/stop a composed task in the middle of one of its subtasks, without throwing an exception?

Throwing an exception does halt tasks (that’s what boot.util/dosh and adzerk.boot-cljs/cljs do, for instance), but it also leaves an often-not-very-useful stacktrace from inside the Boot task’s implementation every time—pushing upwards whatever output occured before the exception, out of view.

Or, rather, is there a way to halt a chain of tasks after a watch task, without having to show a huge Clojure stacktrace from within the exception-throwing task’s implementation? (I’m already at *verbosity* 1, the default, of course. But the stacktraces are still so long, heh.)

(deftask foo
  [c skip-classification bool ""
   l limit VAL int "Limit of records"
   b batch-size VAL int "Batch size"]
  *opts*)
(foo "-b" "10" "-l" "10" "-c" "true”) ;;=> {:batch-size …, :limit …, :skip-classification …}
(foo "-c" “true” "-b" "10" "-l" "10” ) ;;=> {:skip-classification …}

why are some options missing in the last one?

@borkdude you mean there are not {:limit 10 :batch-size 10} in the *opts* map?

oh i see the problem

the -c option is a flag

(foo "-c" "true" "-b" "10" "-l" "10")
            ^
            |
            +- flag does not take optarg, so
               this is interpreted as the start
               of the positional parameters

for example:

boot.user=> (deftask foo
       #_=>   [c skip-classification bool ""
       #_=>    l limit VAL int "Limit of records"
       #_=>    b batch-size VAL int "Batch size"]
       #_=>   [*opts* *args*])
#'boot.user/foo
boot.user=> (foo "-c" "true" "-b" "10" "-l" "10" )
[{:skip-classification true} ("true" "-b" "10" "-l" "10")]

ah!

thanks

Off the top of your head, is there any reason a require inside a boot pod/with-eval would take 4 seconds, but outside of it (but still inside a deftask) it takes less than a millisecond?

@levitanong could be some namespaces are already loaded outside the pod

@martinklepsch Was more wondering why the require inside with-eval was taking so long though 😛 4 seconds seems rather absurd

right, so these namespaces need to be loaded in the pod potentially adding up to 4 seconds. With a repl this is done once during startup.

Ah, I see.

but with a pod :refresh, does it go through the loading process again?

I ask because the 4 seconds happens with every reload

my task is based off your boot-garden, (except I’m trying to work with colocated queries in om.next) and I don’t recall boot-garden taking 4 seconds every reload

refresh gives you a new pod without anything loaded

@levitanong it used the pod's :init option which might be interesting

you can use that to pre-load certain unlikely-to-change namespaces

ahhh

ok that makes sense. Thanks @martinklepsch!

does the cljs task have any options for cache-busting, or even just name rewriting? e.g. my other js build pipelines introduce the git-sha into the final output file, so I get something like fd871j2.bundle.js. I cannot seem to find a way to declare :output-file-name or something of that ilk.

@lwhorton No. This is best handled by another task or code on the application side.

I usually just append md5 hash of the file as query string to the script url. This is easy as I generate the index.html from Clojure and the file is available on classpath.

If you want to rename the file, sift task can do that.

i c. ill have to come up with something for the index.html ‘cause I dont generate that from clojure

at least I know its not supposed to go in boot, thanks

If the index.html is available on fileset, you could write a custom task to edit the script tag with enlive or just regex.

@micha You said that boot had the built in ability to resolve release versions. Which function are you referring to? Is it https://github.com/boot-clj/boot/blob/master/doc/boot.pod.md#resolve-release-versions?

@kenny yep that's one, there is also the show -u task

I thought the boot.pod ns was not on the classpath for new pods - e.g. If I launch a REPL I won't be able to call functions from boot.pod?

boot.pod is accessible in any pod

boot.core currently is not

What about boot.aether? resolve-release-versions calls boot.aether

it calls it in the worker pod though

Ah

with-call-worker ...

the aether stuff is all in the worker pod

many hairy dependencies in there

That's super cool! I didn't know pods could communicate like that

a lot of the functions in boot.pod namespace are just proxies for calling functions in the worker pod

Is the new env returned immediately?

yes, it's synchronous

it doesn't change the environment

it just returns a map

The docs make it sound like it returns a new env map

right

that's what it does

it doesn't change the classpath or anything like that though

it just computes the env map

Gotcha

Thanks 🙂

that function should do it, right?

what you want

Think so. Going to test it out right now in my own boot-new template and, if it makes sense, submit a PR

sweet 🙂

Just to understand a bit better.. When I run boot repl in the command line, a worker pod and core pod are spun up until the REPL is closed, correct?

the core and worker pods are started by boot before any of your code runs

your build.boot runs in the core pod, for example

or if you do boot repl the logic that decides which tasks you want, parses command line arguments, etc, all of that is in the core pod

the worker pod needs to be started before the core pod, because it's going to resolve dependencies the core pod needs

things like that

so whenever boot is running there are at least two pods running, the worker pod and the core pod

That makes sense. I remember reading somewhere that someone was considering using boot as an entry point for their application. The downside to doing that would be the additional hardware required to run at least two pods, right?

Also, isn't there a function in boot that wraps a string read from a clj file in a list?

could I theoretically use boot with scala?

@tmtwd Yes

sweet

@kenny the only thing pods need is about 10M of memory

depending on what you add to them, of course

🐬

@micha Is there a way to get-env without throwing an error when a directory is missing?

like :source-paths or something missing?

Yeah

Like a directory specified in :source-paths is not there

Right now an exception is thrown

I want to get-env specified in an arbitrary build.boot file.

Really I only care about getting :dependencies and :repositories

I guess I can just get the current env instead. Not as general but that is a fair assumption I think