Fork me on GitHub
#boot
<
2016-03-11
>
smw04:03:12

Assuming I’ve required/refered with-prewrap, does this look like a valid way to start an auxiliary server via a boot task, without effecting the build in any other way?

smw04:03:21

(defn start-dirac! []
  (require 'dirac.agent)
  (let [dirac-boot! (resolve 'dirac.agent/boot!)]
    (dirac-boot!)))

(deftask dirac
  "run dirac agent"
  [] 
  (with-pre-wrap fileset
    (start-dirac!)
    fileset))

micha11:03:12

@smw: that looks good to me

micha11:03:29

you might want to use a tactical delay in there

micha11:03:41

so you only start the server once:

micha11:03:55

(deftask dirac
  "run dirac agent"
  []
  (let [dirac (delay (start-dirac!))]
    (with-pass-thru _ @dirac)))

micha11:03:33

the with-pass-thru macro emits the (with-pre-wrap fs ... fs) pattern

micha12:03:05

with the delay you can now safely do like boot watch diract cljs ...

micha12:03:27

and you don't need to worry about having multiple dirac servers trying to use the same ports or whatever

micha12:03:17

also there is the cleanup macro you can use to stop the server when the pipeline finishes

micha12:03:27

this is useful when you're running tasks from the repl

micha12:03:36

because you might start and stop the pipeline

micha12:03:02

so you'd finally have something like this:

micha12:03:37

(deftask dirac
  "run dirac agent"
  []
  (let [dirac (delay (start-dirac!))]
    (cleanup (.stop @dirac))
    (with-pass-thru _ @dirac)))

micha12:03:54

the .stop business there is just an example

richiardiandrea16:03:42

@smw how do I try it? Do you have a branch?

smw20:03:54

@micha: Delay provides idempotence somehow?

smw20:03:46

@richiardiandrea: Not yet, but I’ll try to later today. Few bugs simple_smile

micha20:03:20

@smw: yes, it memoizes

smw20:03:30

Ahh, wonderful, thank you.

micha20:03:52

you use deref or force to get the value

micha20:03:29

and that forces evaluation of the body

smw20:03:03

Ahhhh. That’s just a clojure core func. Somewhat like a promise? Got it.

smw20:03:47

Thanks very much. I was thinking I was going to have to inject a file into the fileset and test that for idempotency

smw20:03:04

I’ll try to package this up into a redistributable task.

nha21:03:12

Is there an example of multiple builds with boot-cljs ? I have several src/cljs/js/myfile.cljs.edn, each setting an :asset-path which works fine but in the end none of them have goog defined (it is compiled alone in out) while the others are in target

smw21:03:55

I have a similar situation with no :asset-path set and it works

smw21:03:12

are you using :init_fns?

nha21:03:53

yes, for all 4 edn files

nha21:03:59

It was working with 2 files though

micha21:03:56

@nha: each build should have its own out

micha21:03:09

are you sure you need :asset-path?

micha21:03:30

usually you can just put the .cljs.edn file where you want it and everything will be taken care of for you

nha21:03:46

Ok - the thing is I was sharing some code when I had two edn files. One was importing the other. I think I did that because there can be only one instance of the google closure library (?)

micha21:03:18

each one should have it's own separate code

micha21:03:25

they shouldn't be sharing anything

micha21:03:38

they will have their own instances of goog and everything

micha21:03:16

i would try a simple example to start with, just multiple .cljs.edn files without any :compiler-options or anything like that

micha21:03:40

once you start specifying compiler options directly there are many things that will go wrong

micha21:03:48

because the options are very difficult to get right

nha21:03:22

Yes I realised that (in fact that went very wrong and my lein file quickly became huge at the time)

nha21:03:30

The two I am trying to add now are devcards though

micha21:03:47

boot-cljs has some hard-won code in there that knows how to set the compiler options in all the different cases

smw21:03:48

{:require  [rl-devcards.cards]
 :compiler-options {:devcards true}}

micha21:03:15

is :devcards built into the cljs compiler now?

smw21:03:17

that’s my devcards.cljs.edn

smw21:03:25

I dunno, it works perfectly

micha21:03:31

i think it ignores that

smw21:03:46

I think I got that from the same example @nha just linked.

micha21:03:48

i'd be surprised if devcards were built into the cljs compiler itself

micha21:03:54

that would be very strange

micha21:03:31

i dont see it there

smw21:03:17

do options get passed through somehow?

micha21:03:33

interesting

micha21:03:54

there is a macro in the devcards cljs somewhere that snoops out the compiler options

micha21:03:02

so that isn't for the compiler it's for that macro

micha21:03:19

that looks like the one

alandipert21:03:59

what a scheme

nha22:03:04

Regarding my question earlier : I am building a SaaS service. Distributed via a js (well cljs) script. So I need to be able to build the script separately. I also need to demo/test it in a frontend site and in devcards (hence my 4 edn builds).

nha22:03:31

(yes I god sidetracked into figwheel for a while ^^ )

nha22:03:53

Oh ok I think I see now what micha meant

nha22:03:11

"each one should have it's own separate code"

nha22:03:17

Thanks will try simple_smile

esp122:03:14

every now and then i come across boot dependencies with :scope “test" qualifiers. what does this mean exactly? is this documented anywhere?

micha22:03:55

it's documented int he maven pom.xml docs

micha22:03:13

the main idea is to help you manage transitive dependencies as a library author

micha22:03:28

so suppose you are writing a library that you will publish as a maven package

micha22:03:50

and suppose your library has certain dependencies

micha22:03:11

like for example if your library uses functions from the clj-time dependency

micha22:03:28

that's a transitive dependency because anyone who uses your library will need to pull in clj-time too, right?

micha22:03:06

so you specify that in your pom, so maven will automatically fetch clj-time transitively when your library is a dependency

micha22:03:39

ok so what about dependencies that are only needed when building or testing your library?

micha22:03:56

you want to have something in the pom about those dependencies so that people can build or test your library from source

micha22:03:26

but you don't want people who use your library as a jar to have to pull those dependencies in transitively, right?

micha22:03:45

because they're not needed when you use the library, only when you build or test it

micha22:03:00

so that's what :scope "test" is for

esp122:03:47

ah ok - i’m familiar with the maven scopes, i just wasn’t sure if they were the same for boot. does boot use maven dependency stuff under the covers?

micha22:03:13

yes, via the pomegranate, which is a clojure wrapper for apache aether, which is the maven thing

micha22:03:29

maven itself also uses aether, as does leiningen

esp122:03:21

ok cool, thanks for the explanation!