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

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

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

@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

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

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?

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

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

boot sift -R PATH repl ?

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

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

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

boot -s dev-resources repl should work

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

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

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

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

i don't usually have any dev-only resources

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

pipelining. see "a better way" in https://github.com/boot-clj/boot/wiki/Cider-REPL

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

test
  code
  resources

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

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

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

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.

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

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

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

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

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.

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?

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 '

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.

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

so you can pass different paths to different rules

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.

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.

also they refer to named places on the filesystem

ie things that the user might own

not to anonymous files in a temp space

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

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

the fileset contains information not only about the names of things

but also their contents

so it contains enough information to reconstruct the original files

given a fileset object

sourcesets only contain information about names

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

in the classic mutable style

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.

transparent

what are flavors?

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.

just permutations, really.

ah yeah

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

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

nice thing about boot: no mystery.

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.

sorry, "as part of task defns"

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.

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

@mobileink: definitely wanted to avoid dependencies

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

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

@richiardiandrea can you share the code?

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

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

everything is idiomatic, nothing is forbidden

the motto of interzone

@mobileink: here you go: https://gist.github.com/arichiardi/d6b98614835039adec59

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

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)

this is a project with both frontend and backend in it

ah yeah i remember the deps issue now

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

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

yes, so you need a global set-env!

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

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

thank you! will examine when I get home.

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

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

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

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

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?

just looking at the build task.

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

sorry, demo.boot

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

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

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 😄

that's why boot is awesome

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

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

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.

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

man is the buzzword of the year! 🙃

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

haha thanks @mobileink 😄

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

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.

ahhahahahaha

nice 😄