Fork me on GitHub
#boot
<
2017-01-27
>
micha00:01:19

snapshot versions are pretty complicated

micha00:01:46

they don't really work the way you'd expect though, so maybe there are unfortunate design decisions in the maven repo system

qqq00:01:52

I'm inside "boot repl" how do I, via the repl, say: "AOT src/simple/HelloServlet.clj " ?

micha00:01:01

i simply avoid SNAPSHOT versions

qqq00:01:29

@micha: is SNAPSHOT the same as RANDOM ?

micha00:01:47

@qqq (boot (aot :namespace #{'simple.HelloServlet}))

qqq00:01:22

@micha: thanks! after seeing the line, it's so %*#&$ intuitive

micha00:01:34

you can also do (doc aot) in the repl

micha00:01:43

to see how to make the kwarg style arguments

micha00:01:52

it has type info and whatnot

micha00:01:59

so you know what type the option arguments are

qqq00:01:05

yeah, part of the problem was that I did not realize the AOT was called "aot"

qqq00:01:08

that's way too simple

qqq00:01:13

I was expecting some complicated incantation

micha00:01:14

like in that case you'll see #{sym} which means set of symbol

kenny00:01:30

Right. We’ve had this discussion before. Unfortunately that doesn’t work well for our company because we iterate on code very rapidly. It is very easy to forget to increment the version number causing us to run out of date code. The snapshot system would work perfectly except for the the way the local install works. If you locally install a snapshot it seems to override any snapshot with a timestamp in the name.

micha00:01:35

you can do (boot "-h") in the repl to see all the available tasks too

kenny00:01:53

I was thinking about writing a custom install task that manually sets the jar name to have the timestamp but I’m not sure if that would solve the problem

micha00:01:10

how could your local snapshot have a timestamp older than a snapshot you previously downloaded from a repo?

kenny00:01:25

No no. If I do boot pom jar install there is no timestamp

micha00:01:38

i mean if it were to generate a timestamp

micha00:01:53

that timestamp would be later than anything you have in the repo already

micha00:01:03

so it should override those things

micha00:01:06

i would think

micha00:01:36

how about you push regular versions with a timestamp in the version number

micha00:01:48

then you can do [my/dependency "LATEST"]

kenny00:01:22

The problem is that if you ever do boot pom jar install then even a week later that old non-timestamped SNAPSHOT jar would override the latest timestamped SNAPSHOT jar pulled from the repo

micha00:01:32

your local version could be like :project 'my/dependency :version (str "1.2.3-" (System/currentTimeMillis))

micha00:01:03

or rather

micha00:01:17

your local version could be like :project 'my/dependency :version (str "1.2.3-r" (System/currentTimeMillis))

micha00:01:27

maven knows how to sort version numbers

micha00:01:00

i think nobody in maven world wants to support SNAPSHOT versions very well, it may actually be impossible

micha00:01:15

they're Considered Harmful by many

micha00:01:30

i believe the timestamp business on the SNAPSHOT jars in the repo is an implementation detail basically

micha00:01:56

but incorporating the timestamp into a legit version seems like what you want really

micha00:01:16

until 2037 or whatever when the epoch rolls over

kenny00:01:08

Well, the main problem with that is then I’d need to update every dependent project with the latest version. Using RELEASE isn’t ideal because it’s possible there is a later version of the code pushed to the repository

micha00:01:32

oh wait, LATEST doesn't really work in my experience

micha00:01:35

i meant RELEASE

kenny00:01:44

I assumed that

micha00:01:53

you can use version ranges

micha00:01:05

it's no worse than using snapshots

micha00:01:32

[my/dependency "(1.2.0,1.3.0)"] or something like that

micha00:01:01

and the "patch" level version could be the unix timestamp

kenny00:01:06

Hmmm, actually that might work

kenny00:01:18

I feel dirty using version ranges though

micha00:01:27

snapshots are probablly worse though

micha00:01:38

because snapshots are somewhat nondeterministic in my experience

micha00:01:18

they're special cased in a lot of places int he maven machinery i think

micha00:01:23

like special caching rules etc

micha00:01:27

pretty gross

micha00:01:30

i hate them

kenny00:01:06

Yeah totally but I think our use case is kinda unique. We are a small team with ~100 libraries, all of which are pretty much always changing. We always want the latest version of the code, even if it is broken, without needing to update 10+ projects to the latest version number.

micha00:01:38

sort of like the google setup

micha00:01:55

with the monolithic repo of everything google

kenny00:01:27

Yeah, I’ve thought about that but it is a pain to manage

micha00:01:49

version ranges might work

kenny00:01:59

I’m thinking that’d do it

micha00:01:04

i guess your maven repo will get pretty big over time

micha00:01:13

but rm -rf is a thing

kenny00:01:25

And storage is cheap

kenny00:01:40

plus these jars are so small it’s basically nothing anyway

micha00:01:20

you know, another option is to just force push to a single version

micha00:01:40

like if you really just want to run the bleeding edge all the time

micha00:01:55

seems like mutable artifacts would be good there

kenny00:01:35

We are using S3 for our repo so that’s already a thing. The problem is there is no way to pull them down

micha00:01:10

you mean like use boot to get artifacts from S3?

micha00:01:23

there are "wagons" for that that work with boot

kenny00:01:43

We use that ^

micha00:01:46

we use S3 repos at adzerk too

kenny00:01:27

There is no mechanism in there to block overwrites for non-snapshot versions

kenny00:01:44

Whereas clojars wouldn’t let you do that

micha00:01:53

oh interesting, i didn't know that

micha00:01:06

maybe that would be useful for your situation?

micha00:01:14

just overwrite the same version

micha00:01:32

i guess if it's in the cache though

kenny00:01:37

The problem is always getting the latest version pulled to your computer

micha00:01:43

interesting

micha00:01:59

yeah i guess that's not a great solution 😄

kenny00:01:44

I think version ranges will work. Though the docs kinda suck. Is this a thing ”0.1.*”?

alexmiller00:01:47

There is a special version "LATEST"

alexmiller00:01:09

I don't think the star is a thing

kenny00:01:22

Yeah, we talked about LATEST but for the reasons I mentioned earlier, it won’t work for our situation 🙂

micha00:01:30

i think it uses like the math interval type notation

seancorfield00:01:44

Yeah, with [ and ) type stuff

alexmiller00:01:56

Sorry, reading from the end

alexmiller00:01:32

Version ranges are broken in some weird subtle ways

seancorfield00:01:34

”[0.1.0,)" should do what you want.

seancorfield00:01:53

Aye, best to avoid them if you can — “here be dragons!"

kenny00:01:05

We have a very unique situation 😉

seancorfield00:01:13

This page has examples of Maven-compatible version ranges: http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html

alexmiller00:01:47

I've been getting notifications on this one for better part of a decade https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-3092

kenny00:01:48

Hmm, not sure if version ranges will actually work because I don’t want the latest given a lower bound — I want the latest of an exact version, regardless of the timestamp/patch

micha00:01:09

i think if you avoid version ranges in transitive dependencies it should eliminate most of the pain

micha00:01:56

like if you don't put version ranges in a pom

micha00:01:07

and you only use them in your :dependencies vector

micha00:01:12

at the application level

micha00:01:20

that might help keep things sane

micha00:01:43

remember that the :dependencies at the application level will override transitive dependencies

micha00:01:54

so your poms can have like the last known good version in them

alexmiller00:01:34

You can use an open range like [0.1.0,) I think

kenny00:01:03

Oh wait, I think [0.1,0.2) would include 0.1.* < x < 0.2.*, where the third number is the timestamp

alexmiller00:01:05

Or [0.1.0,0.2.0)

kenny00:01:12

Hmm, I wish there was a cleaner way. It makes me sad that we are stuck with maven

kenny00:01:40

Actually I bet I could write a super awesome wrapper around set-env! that replaces snapshot versions in our group with the correct version range

micha00:01:14

^^ totally!

micha00:01:28

that's the fun thing about being able to compute in there

micha00:01:45

a macro here, a wrapper fn there, boom in business

micha00:01:32

you could even alter-var-root on #'boot.core/set-env! lol

micha00:01:49

nobody will judge you

micha00:01:24

you work for me computer

kenny00:01:35

TBH, that’s what I was thinking. It’d be transparent and it wouldn’t require a huge code change

micha00:01:02

and snapshots are wonky anyway, this would be an improvement probably

micha00:01:24

i guess the issue is that it wouldn't work transitively

micha00:01:41

you'd need to go a little deeper into the dependency resolution fns

kenny00:01:23

Hmm, not sure if that’ll be a problem

kenny00:01:44

Most of the times the dep is explicit but that seems like it could easily happen

kenny00:01:06

So then what would be the answer there? Walk the dep tree?

kenny00:01:21

Do snapshots work transitively?

micha00:01:37

i mean like if you depend on a thing that in turn depends on a snapshot

micha00:01:49

(which is Discouraged generally)

micha00:01:16

there is also the with-cp task that maybe would simplify things?

kenny00:01:20

Again, special situation 🙂 None of this code is ever “production” code. It’s mostly research stuff

micha00:01:30

that will get you out of maven world and into jars on classpath

micha00:01:09

it lets you separate the dependency resolution completely from the build process

micha00:01:25

so you'd have a lot more control and less opportunity for maven to get weird on you

kenny00:01:04

I’m not sure where with-cp would come into play

micha00:01:49

you can use it to set up the classpath from a file of jar paths, like the -cp java option

micha00:01:04

so you could have a separate task that generates that file for you

micha00:01:25

one thing is you can use s3 then without maven versions etc

micha00:01:29

just have jars there

micha00:01:39

and it can copy them, get the latest one, whatever

micha00:01:50

completely eliminate maven

kenny00:01:56

Interesting

kenny00:01:42

where is with-cp?

micha00:01:54

it's built in

micha00:01:00

2.7.1 version

kenny00:01:07

Ah, no docs

micha00:01:12

there are docs

kenny00:01:14

On the wiki at least

micha00:01:17

boot with-cp -h

micha00:01:24

ah yeah i need tp update the api docs

micha00:01:33

we forgot to do that for this version 😞

micha00:01:24

the with-cp task would allow you to have a monolithic type organization

kenny00:01:11

I guess the pain there is I’d still need to interact with Maven

kenny00:01:19

We use lots of OSS

micha00:01:00

with 100 of your own jars all at the bleeding edge i imagine you're pretty careful about changing transitive dependencies

micha00:01:18

so maybe copying those jars to s3 is feasible

kenny00:01:53

Then I’d need to do it every time that library updates

kenny00:01:59

It’s possible that could be automated

kenny00:01:21

I’d need a graph of every dep each project uses

micha00:01:45

more than that, you also want to make sure that there are no conflicts

micha00:01:08

like if the 100 jars depend on 10 different versions of some OSS artifact that would be terrible

micha00:01:38

so given that you need to coordinate anyway, the maven dependency resolution machinery is maybe less of a win

micha00:01:18

without maven at least you know which version of a thing will be on the classpath

micha00:01:24

vs needing to test all permutaitons

micha01:01:52

at least you have a few options to make things easier, not sure if they are good options 😉

kenny01:01:52

Well, the version ranges sounds easier. We just need something that works without spending weeks trying to implement a custom maven 😛

micha01:01:02

haha right

kenny01:01:24

If that doesn’t work then I’ll look into doing something like that. I’d be curious if we could come up with a more stable (is that the right word? 😆) version of Maven

micha01:01:56

i realized recently that apt-get has been doing a fantastic job

micha01:01:15

i realized that i haven't had a single issue with apt in years now

micha01:01:53

alan pointed out that it's an easier job for them though, since it's a distro and all packages are vetted for compatiblity with each other

micha01:01:11

but still it's pretty amazing how it doesn't suck

seancorfield01:01:18

@micha @alandipert I’d like some enhancements to boot-test to mirror functionality in boot-expectations — specifically, options to specify the Clojure version, a startup function (to be called before any tests are run) and a shutdown function (to be called after all tests are run). Are you happy to take a pull request?

micha01:01:37

@seancorfield that sounds great

seancorfield01:01:00

(I notice that you also have —exclusions and —filters but they don’t work the same way boot-expectations‘s —include and —exclude options do…?)

micha01:01:49

hm possibly not

kenny01:01:21

I’ve had a few problems with apt-get in the past. Maybe it was a user error, but I remember I had to uninstall ubuntu-desktop which also caused my linux headers to get removed as well.

qqq01:01:19

(doc target) // talksa bout :dir #{str} my question: is the same file writen to every directory in that set ?

seancorfield01:01:46

@micha PR sent for that… It would be real nice if boot-test had regex-based include / exclude options like boot-expectations too but I suspect I can use the filters option instead…?

seancorfield01:01:48

Hmm, that seems to be for filtering Vars, not namespaces… OK, so how would I actually use —filters? I see it takes an EDN expression… and the filter function is passed a var-under-test…

richiardiandrea01:01:31

@seancorfield I wanted to add those as well, then tried boot-alt-test and the speed is way way better as it does not run them in a pod. And I have never looked back basically.

richiardiandrea01:01:44

Yeah they are missing

seancorfield01:01:03

Well, I need the pods for testing with different versions of Clojure I think?

richiardiandrea01:01:58

Ah yes in your case it probably makes sense true, my use case is more boot watch test

richiardiandrea01:01:14

Sorry yeah I forgot about that case

seancorfield01:01:39

I tend to do boot watch expections -i #”some-regex” to just re-run expectations for the namespace(s) I’m interested in and that works great.

seancorfield01:01:45

Maybe I’ll see if @micha and @alandipert are interested in -I / —includes and -X / —excludes regex-based options for filtering namespaces like boot-expectations has? That would be my preferred approach.

seancorfield02:01:55

(although I did get -f / —filters to do what I wanted: -f '(re-find #"expectations" (str %))’ but unfortunately it still requires every namespace in my project and I only want a subset loaded!)

seancorfield02:01:37

I added a comment to that issue. We’ll see what they say.

seancorfield02:01:13

(my motivation for this is that I’m adding clojure.test compatibility to Expectations and so I’m looking at how that changes our build process)

vinnyataide02:01:58

hello, where does boot-cljs compile the files, I can't find the js result so I can serve in my ring server

seancorfield02:01:08

@vinnyataide You probably need to specify target as a task so that generated files are written back to disk?

vinnyataide02:01:45

@seancorfield hello sean! So I put my target path the same as the resource folder that ring is serving right?

richiardiandrea02:01:54

@vinnyataide it "materialises" on the fileset and if you want to serve it from there you usually use boot-http

vinnyataide02:01:33

@richiardiandrea got it!

vinnyataide02:01:37

I made a route in compojure, since I'm using my own http server I can't work with boot-http

vinnyataide02:01:42

maybe with CORS that could work, I'm trying to make my system as trivvial as possible http-wise, I'm gonna rely more on sockets to build a webapp

vinnyataide02:01:12

I'm thinking that compojure is adding some unnecessary layer but whatever

richiardiandrea03:01:59

Yeah well boot-http accepts a handler as well, so you might want to pass your handler...Or if you want to use your own server for serving files the clojurescript stuff should be in resource so you can try using to return it from some handler

ag03:01:31

does anyone know how to set “—namespaces” for test-cljs from command line? I need to pass multiple namespaces. this doesn’t work: boot test-cljs --namespaces [”baz" “bar”])

ag04:01:33

the actual problem is: it seems you can tell it to run specific namespace, but then it fails (because that namespace with the test depends on other things). So how do I tell it to include everything, exclude all the tests, except the one I want to test?

ag04:01:44

from command line?

micha04:01:28

@ag options take at most one argument

micha04:01:48

so to pass multiple namespaces you can simply use the --namespaces option multiple times

micha04:01:45

the --help docs for that option should say something like -n, --namespaces NS Conj NS onto the set of namespaces to test.

ag04:01:13

so how do I do the exact thing? still a bit not clear to me. I want test-cljs to run for only one namespace, but when I tell it so like this boot test-cljs —namespaces “.*foo-test.*”, for some reason it’s failing, I can’t figure out why. When they run together it’s fine

ag04:01:29

so I thought maybe I just exclude all the tests include add foo-test, can’t figure this either

micha04:01:40

hm i'm not sure how that works

ag04:01:50

I have test.check.clojure-test/defspec in the test file, when I run test-cljs with no params - it’s fine. when I run telling it —namespaces “^.*foo.*$” it complains

ERROR: Invalid :refer, var clojure.test.check.clojure-test/defspec does not exist in file 

micha04:01:13

a .cljc issue perhaps

micha04:01:17

or something

ag04:01:49

hmmm, interesting thought… I have shared specs in .cljc namespaces

pupeno10:01:07

I completely deleted /Users/pupeno/.boot/cache but when I run boot package, it looks like it’s not re-doing previous tasks that are needed now that the files are gone.

pupeno10:01:19

What’s the proper way to clean a project in boot?

martinklepsch10:01:14

@pupeno there’s no such thing as cleaning since state isn’t carried over between boot invocations

martinklepsch10:01:50

@pupeno can you describe you problem at a higher level?

pupeno10:01:32

@martinklepsch Sure. when I run boot package, the first thing I should see is the download of the package, but it jumps straight into minimizing js and css: https://github.com/pupeno/packages/blob/react-toolbox/react-toolbox/build.boot

pupeno10:01:45

For example, I’m not seeing the output of running npm.

pupeno10:01:49

I used to.

martinklepsch10:01:45

@pupeno try commenting out the println lines inside the comp

martinklepsch10:01:56

@pupeno you can’t compose nil 🙂

martinklepsch10:01:53

What the comp does there is constructing the task pipeline. It’s not actually being ran at that point. So your printlns will also print at the “construction time”

pupeno10:01:03

Right… I missed that. Thanks.

martinklepsch10:01:07

you want to print when the build pipeline reaches a certain stage you’ll need to use something like this:

(with-pass-thru _
  (println “Reached level 9000”))

pupeno10:01:10

It’s working now.

martinklepsch10:01:42

Great! Thanks for packaging something! 😊

pupeno11:01:16

Another noob question...Writing react-toolbox-1.3.3-0.jar… where is it?

martinklepsch11:01:44

@pupeno somewhere in boot/cache — you can use target to have it dumped into target/ or install to have it installed into your local .m2/

pupeno11:01:40

@martinklepsch I’d rather not do that as it goes against cljsjs style, but do you know how I can just manually install it?

martinklepsch11:01:17

@pupeno not sure I understand the question, is the install task not doing that?

pupeno11:01:20

I don’t want to add an install task

martinklepsch11:01:47

because you don’t want to add it to the build.boot file?

martinklepsch11:01:12

tasks can be composed in build.boot or on the CLI so you can just do boot package install

pupeno11:01:15

I’m just following the style cljsjs seems to have.

pupeno11:01:27

Ah… let me try that. Thanks.

pupeno11:01:37

(I’m sorry, I’m very new to boot)

pupeno11:01:27

And then I forgot about point 7.

pupeno11:01:38

I’ve been stuck in point 6 for days.

martinklepsch11:01:27

Sorry about that 🙂

pupeno11:01:39

I will need nevertheless to copy that jar to another machine and manually installed into the .m2 repo

martinklepsch11:01:45

gotta do what you gotta do 😄

qqq13:01:50

how can I tell (boot aot) to also dump clojure classes ?

qqq13:01:17

right now in ./target/... it only dumps class files for (1) my clj files and (2) parts of libaries my clj files depend on

qqq13:01:30

I want it to dump more, i.e. the version of clojure my code depends on as well

micha14:01:33

@qqq dump?

qqq14:01:57

@micha ^^

micha14:01:07

uber just explodes jar files into the fileset

micha14:01:27

so anything that is in the jars will be dumped into the fileset

micha14:01:37

including class files, READMEs whatever

qqq14:01:53

================== Is there an example of how to use watch? I've read (doc watch), and I tried sticking it as

(comp
  (watch)
  ... rest of my task ...
)
but it compiles once, then it ends; I want a "watch task" which infinite loops, watiting for changes, then recompiling

micha14:01:09

that's what watch does

micha14:01:34

paste ... rest of my task ... there is probably an issue there?

qqq14:01:50

@micha: (re uber): so I'm using the gae dev server, which needs stuff to be in the war/WEB-INF/classes directory -- is there a way to "copy the jar" without "explding it" -- gae was complainig about being unable to find clojure/lang/Var until I "exploded the clojure classes" in it via (uber)

qqq14:01:56

sure, 5 secds (on other machine

micha14:01:00

for example, you can do this just to see how it works:

micha14:01:07

boot watch show -f

micha14:01:13

then save a source file and see

qqq14:01:36

@micha: I figured out my boot/watch problem. I forgot (load-file "build.boot") 🙂

qqq14:01:42

so it was running the old, pre (watch) version

qqq14:01:59

@micha: for wars, do I have to "exlode the jar" via uber, or can I just somehow copy the jar over and point to it?

micha14:01:22

there is a :as-jars option to uber that will do what you need there

micha14:01:45

if you want to have the jars in your war in the lib dir or whatever

micha14:01:55

(uber :as-jars true) i think it is

tmarble14:01:17

Hey everybody.. for those that use boot + CIDER to do ClojureScript + Clojure development I just wrote a technical study on setting up a Dual CLJS + CLJ REPL Big thanks to @martinklepsch and @clfeming for helping out! Please take a look and suggest improvements! https://github.com/tmarble/tenzing3

micha14:01:48

@qqq (doc uber) will be helpful

qqq15:01:48

@micha: yeah, read through that, unfortunately, :as-jars true prepends some hash to the jars, which the war then has problem picking up on

micha15:01:16

@qqq how so? why would it care about the jar file name, it should just be on the class path

micha15:01:04

the application should just be loading classes, whose names are not related to the jar file name in any way

richiardiandrea15:01:16

@tmarble funny because two days ago I contributed a patch for fixing cider-jack-in-clojuriscript in cider ;) https://github.com/clojure-emacs/cider/pull/1928

richiardiandrea15:01:34

So now basically what you have to do is just to change cider-boot-parameters to point to the dev task

tmarble15:01:14

@richiardiandrea ooh.. .i'll look at that. FWIW I set my cider-boot-parameters to cider-boot that can be customized in each build.boot (as to avoid twiddilng the customization every time)

tmarble15:01:03

@richiardiandrea do you have any example projects where you show how you use (in your workflow) cider-cljs-boot-repl ? Separately it seems to me that wrap-cljs-repl injects a call to weasel.repl/connect which works in Cursive, but not in CIDER due to either 1) there is no "default" multimethod on handle (causing the application to crash) https://github.com/adzerk-oss/boot-reload/blob/master/src/adzerk/boot_reload/client.cljs#L35 and/or 2) timing (the nREPL may not be set up to send the proper (:type msg) ??

qqq15:01:41

I'm reading boot --help , but I don'ts ee an option for this: is there a way to speify a different location for build.boot ? i.e. I want there to be a server.boot and a client.boot and tell different boot sessions which one to use

micha15:01:51

@qqq you can make namespaces etc

micha15:01:18

you can also use "flavors", as @richiardiandrea does

qqq15:01:15

@micha: I'm sorry, I have no idea what "flavors" and " @richiardiandrea " means

alandipert15:01:31

at the bottom of boot -h thre are a bunch of env vars listed, the one you want to specify alternate boot file is BOOT_FILE`

alandipert15:01:42

ie BOOT_FILE=client.boot boot foo bar baz

qqq15:01:55

@alandipert : ah, thanks!

micha15:01:39

@qqq this:

$ boot -e flavor=client repl
nREPL server started on port 39654 on host 127.0.0.1 - 
REPL-y 0.3.7, nREPL 0.2.12
Clojure 1.8.0
Java HotSpot(TM) 64-Bit Server VM 1.8.0_91-b14
        Exit: Control+D or (exit) or (quit)
    Commands: (user/help)
        Docs: (doc function-name-here)
              (find-doc "part-of-name-here")
Find by Name: (find-name "part-of-name-here")
      Source: (source function-name-here)
     Javadoc: (javadoc java-object-or-class-here)
    Examples from : [clojuredocs or cdoc]
              (user/clojuredocs name-here)
              (user/clojuredocs "ns-here" "name-here")
boot.user=> (get-env :flavor)
"client"

richiardiandrea15:01:51

@tmarble mmm I have basically the standard set up boot-reload and boot-cljs-repl for that and no crashes. I actually use the super alpha boot-figreload but OK one thing at the time

micha15:01:35

or:

$ FLAVOR=client boot repl
nREPL server started on port 35713 on host 127.0.0.1 - 
REPL-y 0.3.7, nREPL 0.2.12
Clojure 1.8.0
Java HotSpot(TM) 64-Bit Server VM 1.8.0_91-b14
        Exit: Control+D or (exit) or (quit)
    Commands: (user/help)
        Docs: (doc function-name-here)
              (find-doc "part-of-name-here")
Find by Name: (find-name "part-of-name-here")
      Source: (source function-name-here)
     Javadoc: (javadoc java-object-or-class-here)
    Examples from : [clojuredocs or cdoc]
              (user/clojuredocs name-here)
              (user/clojuredocs "ns-here" "name-here")
boot.user=> (System/getenv "FLAVOR")
"client"

micha15:01:52

tons of ways to have "modes" or whatever, you're just programming in there

richiardiandrea15:01:54

With that in place I just tell cider to launch my dev and as micha always says, it just works 😄

richiardiandrea16:01:20

Ah yeah the above are "flavors" 😁

qqq16:01:32

@micha: just to clarifyk you're saying "instead of client.boot + server.boot", you can just ahve a single boot.build, and have it run different stuff based on the "FLAVOR" ?

richiardiandrea16:01:34

I was using boot -e flavor=prod blabla but it is similar

tmarble16:01:39

@richiardiandrea so the questions is... in your *.cljs do you specifically call weasel.repl/connect as shown here: https://cider.readthedocs.io/en/latest/up_and_running/#browser-connected-clojurescript-repl

richiardiandrea16:01:19

@tmarble no, that is done by the boot tasks internally

micha16:01:44

you can also make tasks:

(def flavor (atom "server"))

(deftask client []
  (reset! flavor "client")
  identity)

(deftask server []
  (reset! flavor "server")
  identity)
$ boot client dev

tmarble16:01:13

@richiardiandrea wow I wonder why I'm having trouble with it? do you have any smallish CLJS apps I could use to try to reproduce?

richiardiandrea16:01:03

@tmarble the project at the end should work but for the cider PR you have to checkout my branch or wait for the merge: https://github.com/arichiardi/figreload-demo

richiardiandrea16:01:56

You will also see an update in the docs you were pointing to

qqq17:01:20

you know those elephants, that as babies, were tied to immovable objects -- and then as grown ups, they have "learned" that plain rope has "infinite strength" -- going from lein to boot is a bit like that, seems so much of the obstacle is unlearning "this is impossible to do"

seancorfield17:01:14

Hey @micha @alandipert — I sent two separate PRs for the additional options on boot-test and noted that if you apply either one, the other likely won’t apply cleanly (the conflict is easy to resolve). LMK if you’d prefer a PR for both sets of options together — or if you have objections to either PR and want changes.

seancorfield17:01:25

I’m slowly converting our Expectations suite over to the new clojure.test-compatible defexpect format so we’ll be using boot-test heavily soon (and will no longer be using boot-expectations, but I’ll continue to support it).

alandipert17:01:01

@seancorfield are they both backward-compatible? is so, a single patch is easiest

alandipert17:01:08

and i would have no qualms merging

seancorfield17:01:42

Cool. I wasn’t sure you’d be as open to the include/exclude regex options as the Clojure version and startup/shutdown options.

alandipert17:01:41

i'm game. i kind of regret the current filtering thing

alandipert17:01:06

but it's cool, we can 'fix' it by adding better things

seancorfield17:01:41

Combined the two PRs and closed the old include/exclude one.

seancorfield19:01:53

@alandipert: thanks for the merge -- will a 1.1.3 release be made?

alandipert19:01:07

i think 1.2.0, workin on it

alandipert19:01:03

ok boot-test 1.2.0 is out 🍾

alandipert19:01:08

thanks for the cool additions @seancorfield