@jeluard: @juhoteperi: I’m currently making some large changes to the lein integration in Cursive which will allow me to integrate Boot more easily. It’ll definitely be post-conj but it will happen!

isn't there a lein new equivalent for boot?

@xifi: No, but you can use lein new to create boot projects

@juhoteperi: I know, was just wondering if there's any reason this particular task hasn't been implemented in boot

Lein templates are too simple to be really useful

Or well, they are useful in few cases

But pretty much the only template I use is the default one

Project initialization just isn't a feature which would benefit from filesets and other things that Boot provides

understand, thanks

Is there a way to parallelize tasks? I have a couple orthogonal concerns in my build pipeline that could benefit from running in parallel.

@jgdavey: we do this in boot-cljs, for example: https://github.com/adzerk-oss/boot-cljs/blob/master/src/adzerk/boot_cljs.clj#L218

Cool. Thank you!

@micha: @juhoteperi: that cljs task is awesome

@micha Is that parallelizing builds for multiple cljs configs?

Basically, I want to build cljs while also uber-ing.

(clojurescript/clojure jar)

@jgdavey: the parallelization in the cljs task is cljs-task specific

@jgdavey: you can write some coordination logic using futures just like they do, there

there isn’t any general approach in parallelizing tasks but from previous discussions it seems possible

you can also just REPL in and do (do (future (uberjar)) (future (cljs)))

@pandeiro: true enough. I was wondering if I was missing anything for the scripted case. That is, within deftask

howdy boot folks

hi @mathiasx

yeah running tasks in parallel is not so simple

because they mutate global jvm state (i.e. classpath)

i would avoid it i guess

@micha: do pods mutate global jvm state?

no, i guess it's not really jvm global

but the build runtime though

is that a terrible idea to launch tasks from the REPL in (future ...)'s ?

like if task A does commit! on a fileset that will change the classpath for the other task

ooh

pandeiro: no, it's ok, i do that sometimes like a shell background task

and then deref later

i used to have some things for repl job control

but it never was really that awesome

i just kill emacs and leak the memory (?)

but actually i never run tasks in parallel here - it's been a while

doing an advanced compile of 3 .cljs.edn builds on circleci -- anyone want to guess the duration?

250s

low

jeeze

6:10

could the parallelism actually be hurting the perf on a one CPU circle vm?

probably not much yeah?

it's possible

how long does it take to compile one of them?

@micha: with some sort of higher order task it should be possible to merge two filesets that have been computed in parallel and commit! the merged one, right?

@martinklepsch: yes, except that tasks call commit! themselves

right. 😏

i wonder anew about a cljs compiler task -aaS

fileset in, js out

i guess a remote task would need more than the fileset, it needs deps etc

@alandipert: the pod is the seam to pry on there

you could create a remote pod pretty easily i believe

i mean Pretty Easily ™️

as long as the evals are linearized you mean?

i thought you were talking about like cljs compiler service?

yeah i'm just sayin

in the clouds

for pods to be in the cloud and to be the same as a local pod, the evals need to happen in the same order

does seem Easy tho

sky-pod eval is just synchronous

yeah, i think it's probably not productive to try to make it the same as a local pod

like with castra, i think it would probably be better to cleanly delineate the limitations

a fileset can't be passed to a pod either

yeah you'd just zip up all the thiings i guess and send them to the cloud

seems like the time to do that is src/src/asset sync

we kind of already do it

rsync instead lol

So over on IRC the other day I was asking about getting ENV vars that I "stub" with Environ into a pod where my boot-test task is running. Any ideas?

I tried just creating a clojure.test around fixture that uses with-redefs on environ/env but by the time that's actually running for a test is too late in the process; it needs to be there before the namespace is interpreted for the test run

@mathiasx: there is adzerkoss/env which might be interesting

I looked at the README, but I wasn't quite sure how that's gonna help me keep config out of my source

Maybe I should take a step back in my problem and see if I'm missing a better overall solution.

I'm writing a Clojure web app that talks to Postgres, and trying to write a test suite for it. Because I'll eventually be deploying to Heroku, the postgres connection info comes from ENV vars, and that's what I'd also like to use to distinguish between my development database and test database locally.

So I've got various builds set up in my build.boot, and I was using environ to set those env vars before running tasks.

And all that leads to not being able to pass in the test database to the test suite because the pod isolates it.

Ideally, I'd like to keep all that config out of anything that will ever run out on the server, so build.boot tasks that it won't run are fine for setting that, but I'm hesitant to have it in the source.

Is there any way to look at the contents of boot's temporary directories?

@jaen I would immagine you could use this on the temp dir https://clojuredocs.org/clojure.core/file-seq

What I mean is I'm under impression boot blows the temporary directories away as soon as it is done with them, or am I wrong?

I believe this is correct

you can use the show task

show -f for all files in fileset

What I want is to keep that from happening - something I did doesn't work with boot-cljs and I would want to explore the temporary directory to verify something.

Hmm, let me take a look at this option

not sure if that is all the files you are looking for, as I understand it is the fileset from the tasks before it

Yeah, that's not enough - the file I'm lookign for is created during cljs compilation and the compiler blows up before the task finishes

So I imagine the temp directory is gone as well

dont know enough to say when exactly the temp file sets are removed

I thought they had to be cleared but that may just be from earlier tasks in the pipeline

the wiki is great !!https://github.com/boot-clj/boot/wiki/Filesets

@mathiasx: if you have JVM-global environment you can't store those in Clojure vars, because those only exist in a specific Clojure runtime

if you set system properties or actual environment variables then environ will work

environment is basically not the same thing as clojure vars

what we do is we configure database connections and whatnot in environment variables

@jaen: what does your task look like?

can you add watch to your task as to avoid boot from exiting?

jaen: boot doesn't delete temp dirs until the next time boot runs in that project

I inspect the cljs files all the time

this is so you can debug things

@flyboarder: nothing too fancy, just usual boot-cljs invocation, I'm using custom clojurescript compiler though

jaen: the temp directory is still there after boot crashes

you can find it by doing like this:

boot show -e cljs foo bar

putting the show -e in the pipeline there will cause it to dump the boot env to stdout

you can look in the :directories key to see the temp dirs

well depending

the cljs task makes its own temp dirs too

so you may need to look in there

but they'll all be under the same subtree in the ~/.boot/cache directory

so you can probably use find and friends to find things