Fork me on GitHub
#boot
<
2016-11-09
>
pseud06:11:57

Say I wanted to rename a bunch of standard boot tasks because I wanted to provide an interface that looked a lot like lein’s interface (I know it’s insane, play along 🙂 )… I saw boot.core/rename-task! … anyone seen this in use ?

micha14:11:46

@pseud you can also use def, no?

micha14:11:28

boot tasks are vars

micha14:11:04

or zach tellman's potemkin library to map names from boot built-in task namespace into your own task namespace

micha14:11:19

tasks don't know what their own names are

micha14:11:40

and they don't know or care about other task's names

micha14:11:51

there is no coupling between tasks in that way

micha14:11:57

that's left to the user

lwhorton18:11:58

hey guys, i was wondering if anyone could speak to code sharing between multiple apps with boot… strategies, pain points, etc? I have two apps foo and bar, where bar grew our of foo over a period of time. Foo contains a whole lot of utility code, everything from library wrappers to reusable components. Would it be best to keep foo and bar as “siblings” and have separate boot files/processes? Should there be a third “core” library that the other two require? Any thoughts would be appreciated.

micha18:11:50

@lwhorton i usually break things out into libraries whenever possible

micha18:11:13

separate jar dependencies

micha18:11:29

especially when you have sharing between applications

micha18:11:43

because with separate jars you can have versions

micha18:11:58

so maybe one application is running an older version of the shared code

micha18:11:16

or if something goes wrong and you need to roll back etc

lwhorton19:11:00

I see.. that’s what I was thinking more or less, its just a bit of work to get everything “libraried” unfortunately

lwhorton19:11:27

and it feels weird doing so for such a small layer around a few pieces - for example, i wrap reagent with 4-5 helpers

lwhorton19:11:44

but I suppose there’s not any alternative that wouldn’t get into version hell

micha19:11:54

personally i either cut and paste or make real dependencies

micha19:11:18

anything in the middle is just a mess of half baked workaround tooling

micha19:11:28

that ends up difficult for the next guy to debug

lwhorton19:11:25

Here comes the repo explosion I’ve been putting off for too long

micha19:11:55

well you can always abandon a library if it is superceded by something better later

micha19:11:17

still better than nothing though probably

lwhorton19:11:21

thanks for the input @micha

lwhorton19:11:45

say I had 5 libraries belonging to “core” - would you run with a separate boot file for each one that builds/publishes the lib?

micha19:11:11

@lwhorton yeah, but it would be pretty minimal

micha19:11:17

just biulds a jar

lwhorton20:11:45

ugh I must be doing something wrong…

(deftask dev
  "Build a jar and install to local maven repo."
  []
  (comp
    (watch)
    (build)
    (install)))

(task-options!
  pom {:project ‘x/my-lib
       :version +version+
       :url “"
       :scm {:url “}
       })
If thats my simple “just build and install locally” boot file; i should be able to either :checkouts '[ [x/my-lib +version+] ] or use :dependencies inside another project’s boot file, and boot should check local /.m2 first, right?

micha20:11:35

for checkouts you want both

micha20:11:41

:checkouts and :dependencies

lwhorton20:11:56

i’m not quite sure on the :checkouts thing, except knowing it’s deprecated

micha20:11:57

the :checkouts is in addition to the dependencies basically

micha20:11:09

the checkout task is deprecated

micha20:11:23

because it was implemented in a much better way as a boot option

micha20:11:27

--checkouts

micha20:11:33

or :checkouts in the env

lwhorton20:11:28

I must be doing something dumb… like a bad character somewhere. If the ns for my-lib is x.my-lib.core, I should be able to (:require [x.my-lib.core :as lib]), but I keep getting a “could not find on classpath” issue

lwhorton20:11:34

ill go take a walk and come back to it I think

Tim21:11:12

@micha is boot.properties a place you can put jvm-opts and other options normally bundled in project.clj?

micha21:11:44

@tmtwd currently the boot.properties is read by the java code

micha21:11:54

so it is read after the jvm has been started

micha21:11:11

we will change this soon

Tim21:11:18

oh ok, so jvm-opts has to be handled outside of boot?

micha21:11:31

BOOT_JVM_OPTIONS env var on unix

micha21:11:41

on windows there is the boot.l4j.ini file

Tim21:11:58

yup, sounds good

kenny23:11:06

When exactly does boot check if a new SNAPSHOT is available?

kenny23:11:22

It doesn't seem to be every time I run boot