Fork me on GitHub
#boot
<
2015-09-18
>
cfleming03:09:49

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

xifi07:09:18

isn't there a lein new equivalent for boot?

juhoteperi07:09:44

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

xifi07:09:19

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

juhoteperi07:09:51

Lein templates are too simple to be really useful

juhoteperi07:09:09

Or well, they are useful in few cases

juhoteperi07:09:23

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

juhoteperi07:09:58

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

xifi07:09:51

understand, thanks

jgdavey20:09:54

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

jgdavey20:09:29

Cool. Thank you!

pandeiro20:09:19

@micha: @juhoteperi: that cljs task is awesome

jgdavey20:09:21

@micha Is that parallelizing builds for multiple cljs configs?

jgdavey20:09:58

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

jgdavey20:09:20

(clojurescript/clojure jar)

martinklepsch20:09:33

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

pandeiro20:09:53

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

martinklepsch20:09:58

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

pandeiro20:09:17

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

jgdavey20:09:14

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

mathiasx20:09:07

howdy boot folks

micha20:09:50

yeah running tasks in parallel is not so simple

micha20:09:04

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

micha20:09:14

i would avoid it i guess

martinklepsch20:09:01

@micha: do pods mutate global jvm state?

micha20:09:33

no, i guess it's not really jvm global

micha20:09:44

but the build runtime though

pandeiro20:09:59

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

micha20:09:03

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

micha20:09:31

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

micha20:09:36

and then deref later

micha20:09:57

i used to have some things for repl job control

micha20:09:07

but it never was really that awesome

pandeiro20:09:13

i just kill emacs and leak the memory (?)

pandeiro20:09:34

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

pandeiro20:09:59

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

pandeiro20:09:13

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

pandeiro20:09:19

probably not much yeah?

micha20:09:39

it's possible

micha20:09:11

how long does it take to compile one of them?

martinklepsch20:09:42

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

micha20:09:11

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

alandipert21:09:52

i wonder anew about a cljs compiler task -aaS

alandipert21:09:12

fileset in, js out

alandipert21:09:03

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

micha21:09:23

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

micha21:09:41

you could create a remote pod pretty easily i believe

micha21:09:54

i mean Pretty Easily

alandipert21:09:56

as long as the evals are linearized you mean?

micha21:09:27

i thought you were talking about like cljs compiler service?

alandipert21:09:34

yeah i'm just sayin

micha21:09:34

in the clouds

alandipert21:09:45

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

alandipert21:09:10

does seem Easy tho

alandipert21:09:16

sky-pod eval is just synchronous

micha21:09:19

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

micha21:09:52

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

alandipert21:09:04

a fileset can't be passed to a pod either

micha21:09:37

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

alandipert21:09:46

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

alandipert21:09:52

we kind of already do it

alandipert21:09:05

rsync instead lol

mathiasx22:09:33

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?

mathiasx22:09:54

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

martinklepsch22:09:11

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

mathiasx22:09:51

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

mathiasx23:09:31

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

mathiasx23:09:21

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.

mathiasx23:09:45

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.

mathiasx23:09:06

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

mathiasx23:09:56

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.

jaen23:09:16

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

flyboarder23:09:29

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

jaen23:09:22

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?

flyboarder23:09:57

I believe this is correct

flyboarder23:09:17

you can use the show task

flyboarder23:09:34

show -f for all files in fileset

jaen23:09:37

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.

jaen23:09:14

Hmm, let me take a look at this option

flyboarder23:09:58

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

jaen23:09:34

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

jaen23:09:43

So I imagine the temp directory is gone as well

flyboarder23:09:28

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

flyboarder23:09:09

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

micha23:09:09

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

micha23:09:35

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

micha23:09:50

environment is basically not the same thing as clojure vars

micha23:09:33

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

flyboarder23:09:43

@jaen: what does your task look like?

flyboarder23:09:13

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

micha23:09:23

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

flyboarder23:09:27

I inspect the cljs files all the time

micha23:09:32

this is so you can debug things

jaen23:09:12

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

micha23:09:01

jaen: the temp directory is still there after boot crashes

micha23:09:09

you can find it by doing like this:

micha23:09:26

boot show -e cljs foo bar

micha23:09:52

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

micha23:09:05

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

micha23:09:15

well depending

micha23:09:28

the cljs task makes its own temp dirs too

micha23:09:34

so you may need to look in there

micha23:09:01

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

micha23:09:19

so you can probably use find and friends to find things