Fork me on GitHub
#boot
<
2016-02-29
>
escherize12:02:26

@hlolli: I don't, but I did just write a tutorial/quickstart for using boot and cljs/reagent. It's here: http://escherize.com/

escherize12:02:46

special thanks to the boot team, @martinklepsch and @magomimmo!!

alandipert13:02:29

@escherize: if you do a tweet, i will retweet

onetom13:02:55

@hlolli: i was just asking a similar question the other day. i notice that on some of the major devcards doc pages they even mentioned boot-reload as an alternative solution if u don't want figwheel

onetom13:02:20

what i would be curious is how to make it friends w hoplon though...

tolitius15:02:20

have a dev-resources that I'd like to be added to resources when repl starts. don't want for it to be included in the build of course. is there a way to do that besides creating a new task i.e. "dev" that would set things up and call a repl?

tolitius15:02:00

rather a simple question, I always used a dev task before, and never needed boot repl to also know about my dev resources. but I just want to understand it a bit better, overriding boot.task.built-in/repl feels very uncouth simple_smile

dm316:02:09

I think there's a -s flag you can use to set (or add to) source dirs

mobileink16:02:36

boot sift -R PATH repl ?

tolitius16:02:06

was thinking more of a boot repl approach simple_smile for a quick shell access

tolitius16:02:32

I can definitely wrap those in a .sh but it is a bit involved for a simple thing like this

tolitius16:02:00

(i.e. in lein you have a dev profile, and lein repl reads it by default)

dm316:02:24

boot -s dev-resources repl should work

micha16:02:42

also -r if you want to add to :resource-paths

tolitius16:02:14

I see, thanks. how do you guys do it, do you not need those resources when you just run boot repl?

tolitius16:02:40

.. use these start options or load them when inside the repl manually?

dm316:02:45

I have the repl started by dev task and don't usually need "just" the repl

micha16:02:22

i don't usually have any dev-only resources

tolitius16:02:38

ok.. I see, so I am not "one off", I thought this is just something I use, and don't know how to boot repl correctly simple_smile

tolitius16:02:36

@micha I arrived to this from the fact that I could not couple test resources under test, i.e.

test
  code
  resources

tolitius16:02:00

so I moved them around to dev-resources, since I use them in dev as well..

mobileink16:02:28

i've only just begun to appreciate the beauty of the CLI pipeline - makes it easy to customize builds on-the-fly

tolitius16:02:46

@mobileink: good read about cider-repl, thanks. I use vi, but still the fact that all can be customized and programmed is great

mobileink16:02:01

regarding dev-only resources: boot makes it possible not only to do that, but have dev-only build structures! very very cool. - i'm finishing up a rewrite of boot-gae that allows you to build and test with or without servlets, filters, security, etc. i don't even want to think about how to do that without filesets.

mobileink16:02:19

so e.g. if you just want to test a single servlet using a subset of your resources, you just select the right subset of build tasks and the output has only the stuff you asked for

tolitius16:02:07

@mobileink: sounds very cursor'ish, not in a bad way simple_smile is boot-gae a new boot google app engine thing that is coming up soon?

mobileink16:02:51

yep. you can take a look at it and start experimenting but the README for the tasklib is a little out of date - you'll need to look at the build.boot and .edn config files in the test app to see what's happening. it's at https://github.com/migae/boot-gae

mobileink17:02:20

@micha, @alandipert : FYI I've redesigned boot-gae along the lines you recommended. if you find a chance to take a look i'd be interested in your feedback. i broke the tasks down into smaller ones, and followed the example of boot-reload in using .edn config files. But with a little bit of a difference: i realized you can pass a master .edn config file through the pipeline, and different tasks can "elaborate" it using their own task-specific .edn files. then only at the end is there a task that takes the master config file and uses it to generate stuff. that was a real revelation! it makes it possible to split the construction of one monolithic output - e.g. web.xml - into multiple independent tasks, so you can easily include/omit whatever you want at dev/prod time.

mobileink17:02:56

for example, you want to use a "reload" filter at dev time to get reload-on-refresh, but you don't want that in production. previously I always had to manually fiddle with config files to handle this - with boot its just controlled by a reloader tasks - you want the filter, run that task; you don't, don't run it.

jaen17:02:36

Hmm, I returned to using boot-cljs-repl after usign dirac (can't use it with PhoneGap/Cordova) and I'm getting this: https://gist.github.com/jaen/0bf18ac8a83cd6d57727 Any idea what I should be looking at to figure out what's wrong?

jaen17:02:39

Ok, when I remove dirac from my dependencies I still get the error, but REPL at least works, so that's probably just some dependency problem, sorry '

mobileink19:02:38

anybody here understand gradle sourcesets? I've been dealing with gradle for a couple years (android, gae) but still do not understand them. I go out of my way to avoid actually having to learn how gradle works. strangely, I tend to go out of my way to understand how boot works. I'd like to contrast sourcesets with filesets but that's hard to do when you don't know what they are.

micha19:02:50

they seem to be a way to group named files on the filesystem

micha19:02:04

so you can pass different paths to different rules

mobileink19:02:28

FWIW I suspect sourcesets are perfume on a turd, they don't really solve any problem, they just move it. whereas filesets are areal solution.

mobileink20:02:54

I get the impression that gradle thinks of sourcesets in a way that is similar to the way one might think of filesets. but they're not first class, they're just a complicated way of collecting strings, in a way.

micha20:02:16

also they refer to named places on the filesystem

micha20:02:24

ie things that the user might own

micha20:02:38

not to anonymous files in a temp space

mobileink20:02:45

I'm trying to come up with a succinct (and polite) way of expressing the diff.

micha20:02:11

it seems like the classic mutable places vs immutable values more or less

micha20:02:27

the fileset contains information not only about the names of things

micha20:02:32

but also their contents

micha20:02:52

so it contains enough information to reconstruct the original files

micha20:02:56

given a fileset object

micha20:02:12

sourcesets only contain information about names

mobileink20:02:13

ah, yes! filesets sever the link between fname and on-disk fcontent (by snapshotting).

micha20:02:18

in the classic mutable style

mobileink20:02:57

I'm looking at the android gradle plugin. lots of sourcesets and other cruft. I think boot could do flavors etc. in a much more simple and trad parent manner.

mobileink20:02:19

transparent

micha20:02:30

what are flavors?

mobileink20:02:15

e.g. demo v. full. in contrast to "build types", e.g. debug v. release. they also add "flavor dimension", e.g. x86 v. arm v. mips.

mobileink20:02:37

just permutations, really.

micha20:02:18

i imagine you could do that in a library and not need to implement it in boot itself

mobileink20:02:20

for flavors I think e.g. demo.boot v. full.boot would do the trick.

mobileink20:02:24

nice thing about boot: no mystery.

mobileink20:02:38

question for the core devs: did you consciously reject the idea of including task dependencies as part of taking defns? when I started with boot that struck me as strange and suspicious for a build tool. now I think it was a wise decision.

mobileink20:02:32

sorry, "as part of task defns"

mobileink20:02:52

it's one thing to say a task depends on a thing; it's an entirely different thing to say it depends on another task.

richiardiandrea20:02:22

@mobileink about flavors, I implemented them with an options multimethod that dispatches on a vector [flavor build-type]. Very easy with boot.

micha20:02:59

@mobileink: definitely wanted to avoid dependencies

micha20:02:09

like we found that it's trivial for the user to know which order the pipeline should be, but extremely difficult for the computer to figure it out from annotations etc

micha20:02:53

i guess that's the philosophy behind everything in there, the user knows what they want to do way better than the tool can know

mobileink20:02:07

@richiardiandrea can you share the code?

micha20:02:22

and lisp provides the means to abstract over any parts that involve boilerplate or tedium

mobileink20:02:39

Power to the People! We don' need no stinckin' conventions! heheh.

micha20:02:48

everything is idiomatic, nothing is forbidden

micha20:02:56

the motto of interzone

richiardiandrea20:02:49

there was a tricky part in handling boot runtime deps so you can see that at line 46

richiardiandrea20:02:08

because the runtime needs the correct deps with set-env! and you cannot change them after that (@micha of course better knows the details and explained me what to do)

richiardiandrea20:02:47

this is a project with both frontend and backend in it

micha20:02:20

ah yeah i remember the deps issue now

micha20:02:46

it was to enable resolving all the deps together instead of in separate steps

micha20:02:06

so maven could select the correct dependencies based on the complete dependency graph

richiardiandrea20:02:08

yes, so you need a global set-env!

mobileink20:02:45

@micha : worst thing is projects that presume to protect us from ourselves.

richiardiandrea20:02:55

make sense actually, it needs it for the boot process to work, then in the task I can customize them further

mobileink20:02:44

thank you! will examine when I get home.

richiardiandrea20:02:57

the second set-env! effectively change them for the subsequent tasks: https://gist.github.com/arichiardi/d6b98614835039adec59#file-build-clj-L159

richiardiandrea20:02:32

I can tell that because the [:backend :prod] final uberjar does not contain backend-dev-deps

richiardiandrea20:02:14

anyways it was fun to implement and I could still get what I wanted, which is awesome 😄

richiardiandrea20:02:02

another flavor can be easily added as it is just an additional multimethod, like (defmethod options [:frontend-ie :prod] [selection] ...)

mobileink20:02:21

how would I say "build the debug version of the demo version"? I see the -t option for :devel but where's the option for demo?

mobileink20:02:09

just looking at the build task.

mobileink20:02:19

the idea that came to me is you have demo.build in BUILD_FILE, so you just do boot debug with that.

mobileink20:02:04

sorry, demo.boot

richiardiandrea20:02:12

@mobileink: debug would be my build type and demo a flavor

richiardiandrea20:02:36

so you add (defmethod options [:demo :debug] [selection] ...)

richiardiandrea20:02:04

but it is up to you, I just wanted to show you the power of having a language at your disposal in your build file, but you know that already 😄

richiardiandrea20:02:12

that's why boot is awesome

mobileink20:02:44

no, boot is beyond awesome. ;) I'll definitely take a good look at your code, thanks for sharing it!

richiardiandrea20:02:44

it may be a bit complected, and I am open to any feedback 😉

mobileink21:02:37

I feel like I have not heaped sufficient praise on the devs for at least a day. you guys are geniuses! Here's a slogan for you: "Boot: Clojure's killer app." At long last.

mobileink21:02:48

@richiardiandrea : ok, please never say "complected" again ;)

richiardiandrea21:02:25

man is the buzzword of the year! 🙃

mobileink21:02:25

(the word you're looking for is "complex", or maybe "complicated".) sorry, crusty old fart here.

micha21:02:32

haha thanks @mobileink 😄

richiardiandrea21:02:14

@mobileink: lol don't say this to Rich Hickey 😄

mobileink21:02:19

haha. Genius? absolutely. Feet of clay? well yes. my nightmare is I'm having a beer with RH and he says "complected" and I go berserk and suddenly all my clojure code steps wroking. such is the fate of liberal arts grads in today's world.