Fork me on GitHub
#boot
<
2016-05-14
>
jupl04:05:38

I’m working on a plugin and would like to know if Boot offers a convenience to get the base directory of a project?

ajchemist07:05:03

@jupl (.getCanonicalPath ( ".”))?

ajchemist07:05:41

and boot.file namespace has many pretty useful utilities AFAIK

ajchemist07:05:43

or maybe this (System/getProperty "user.dir”)?

jupl15:05:25

Can this be used via a boot library?

mobileink17:05:27

I have a task that looks like this: boot watch speak gae/make pom jar install. here gae/make just sifts stuff and ends with a target :no-clean … task. the idea is i don’t want to rebuild everything, only copy the clojure source that has changed. the problem is that the stuff that was already in the target dir is not getting picked up by jar. any way to make the pom jar install pipeline work from the target dir?

micha17:05:14

@jupl: i think (System/getProperty "user.dir") is probably the best way

micha17:05:18

the (.getCanonicalPath (java.io.File. ".")) option should also work, and should be equivalent

micha17:05:41

both of those can be used anywhere

micha17:05:03

@mobileink: the target dir is completely outside of boot, there is no facility to look inside those directories while boot is running

micha17:05:10

it's write-only as far as boot is concerned

micha17:05:18

because it's unmanaged shared global state

micha17:05:55

the target dir is just a place for boot to dump its final state before it exits

micha17:05:03

while boot is running it's in an undefined state

micha17:05:21

there are no guarantees about what should or should not be in there while boot is running

micha17:05:55

if you want to do things while boot is running you can use the classpath or have a task that writes files to a tempdir that you control in a task

micha17:05:19

the target task is a kind of deployment, basically

micha17:05:04

however, if you're trying to optimize the target task there is no need

micha17:05:23

it is already probably as efficient as it can be, it doesn't write anything that hasn't changed

micha17:05:39

it does a pretty optimized filesystem patch thing

micha17:05:03

and will use hard links wherever possible to reduce IO

mobileink17:05:07

well, my build includes a half dozen or so one-time tasks that generate code. how can i avoid rerunning those in my watch task. hm, maybe a cache?

micha17:05:35

you can use the boot.core/cache-dir! function to create a persistent cache in your task

micha17:05:53

it has options for global and project-local caches

mobileink17:05:55

yeah, didn’t think of that, i think it would work

micha17:05:08

depending on what you need

mobileink17:05:09

i’ve used it for other stuff

micha17:05:55

the target task is just a deployment task really

micha17:05:01

like the target dir is a place to deploy to

micha17:05:11

so it doesn't realy make sense for that to be visible in the build

micha17:05:18

since it's a global shared mutable place

micha17:05:40

and not anonymous, so other things will presumably be messing around in there

mobileink17:05:47

good point, it’s the boot way of thinking which I obviously have not quite mastered! btw I got get-checkouts working, i just do a sift to put the checkout content into assets. but that puts everthing into target/ and i can’t figure out how to put it into target/foo/ . tried (builtin/sift :move {(re-pattern "(.*)") "foo/$1”}) but everything ends up with “foo” suffixed.

micha17:05:58

like with "foo/" at the end of the paths?

mobileink17:05:02

e.g. target/index.html becomes target/foo/index.htmlfoo

micha17:05:46

that seems impossible

micha17:05:55

maybe you need to anchor the pattern?

mobileink17:05:16

sth circular i guess. i’m doing ` (comp (builtin/sift :add-asset #{(.getPath (first co-dirs))}) (builtin/sift :move {(re-pattern "(.*)") "foo/$1”})`

micha17:05:00

i think the :add-asset part might not work

micha17:05:08

it's expecting to match on the classpath path

micha17:05:14

i.e. the relative path

mobileink17:05:19

ah, anchoring is the thing, this works: (builtin/sift :move {(re-pattern "(^.*)") "foo/$1”})

micha17:05:32

super weird

mobileink17:05:00

seems to work anyway. maybe doing :move right after :add-asset wierds things out

micha17:05:35

i don't think :add-asset is doing anything

micha17:05:43

disregard that

micha17:05:47

i see it now

micha17:05:12

i was thinking :to-asset lol

mobileink17:05:16

yeah, co-dirs is copied from the uber implementation

mobileink18:05:04

so in any case the mechanism works: watch a component module, jar and install it on change, at the same time watch the installed jar and copy it to the webapp on change. it’s a little clunky and slow but it works. so boot lets us treat gae “service” components (formerly knowns as modules) as separate apps, completely independent of the apps in which they are used. I don’t think you can do with the gradle build system.

micha18:05:52

perhaps the cache dirs will help performance

micha18:05:27

there are also some good functions in boot.core in 2.6.0 that can be helpful maybe

mobileink18:05:20

no doubt there will be various ways to tweak performance, i’ll just be happy when i get the whole thing working correctly...

micha18:05:23

like that guy

micha18:05:42

of course not yet fully documented

mobileink18:05:36

heh. i look forward to the documented version 😉 i’m afraid my head will explode if i do much more code reading today. time to go watch some baseball. Thanks for your help!