Fork me on GitHub
#boot
<
2016-09-27
>
cigitia01:09:18

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?

cigitia01:09:01

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.

cigitia02:09:30

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

borkdude11:09:17

(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 …}

borkdude11:09:39

why are some options missing in the last one?

micha14:09:17

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

micha14:09:33

oh i see the problem

micha14:09:45

the -c option is a flag

micha14:09:19

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

micha14:09:30

for example:

micha14:09:44

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

levitanong16:09:32

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?

martinklepsch16:09:14

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

levitanong16:09:09

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

martinklepsch16:09:59

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.

levitanong16:09:32

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

levitanong16:09:59

I ask because the 4 seconds happens with every reload

levitanong16:09:38

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

martinklepsch16:09:46

refresh gives you a new pod without anything loaded

martinklepsch16:09:40

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

martinklepsch16:09:03

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

levitanong16:09:50

ok that makes sense. Thanks @martinklepsch!

lwhorton16:09:35

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.

juhoteperi16:09:20

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

juhoteperi16:09:11

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.

juhoteperi16:09:24

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

lwhorton16:09:17

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

lwhorton16:09:28

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

juhoteperi16:09:14

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

kenny17:09:09

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

micha17:09:28

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

kenny17:09:49

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?

micha17:09:01

boot.pod is accessible in any pod

micha17:09:13

boot.core currently is not

kenny17:09:43

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

micha17:09:35

it calls it in the worker pod though

micha17:09:41

with-call-worker ...

micha17:09:55

the aether stuff is all in the worker pod

micha17:09:05

many hairy dependencies in there

kenny17:09:12

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

micha17:09:58

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

kenny17:09:06

Is the new env returned immediately?

micha17:09:17

yes, it's synchronous

micha17:09:33

it doesn't change the environment

micha17:09:38

it just returns a map

kenny17:09:53

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

micha18:09:05

that's what it does

micha18:09:23

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

micha18:09:30

it just computes the env map

kenny18:09:42

Thanks 🙂

micha18:09:04

that function should do it, right?

micha18:09:08

what you want

kenny18:09:41

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

micha18:09:56

sweet 🙂

kenny18:09:19

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?

micha18:09:02

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

micha18:09:15

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

micha18:09:50

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

micha18:09:25

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

micha18:09:31

things like that

micha18:09:52

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

kenny18:09:46

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?

kenny18:09:54

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

Tim18:09:58

could I theoretically use boot with scala?

micha20:09:13

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

micha20:09:26

depending on what you add to them, of course

kenny20:09:06

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

micha20:09:55

like :source-paths or something missing?

kenny20:09:54

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

kenny20:09:59

Right now an exception is thrown

kenny20:09:52

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

kenny20:09:14

Really I only care about getting :dependencies and :repositories

kenny20:09:34

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