Fork me on GitHub
#boot
<
2015-12-17
>
pleasetrythisathome00:12:24

seems like boot 2.5.0 is breaking some boot tasks

pleasetrythisathome00:12:26

getting cli errors

pleasetrythisathome00:12:27

java.lang.Exception: cli: option notifier: expected optarg, got sym

pleasetrythisathome00:12:02

clojure.lang.ExceptionInfo: cli: option notifier: expected optarg, got sym
    data: {:file "jeluard/boot_notify.clj", :line 44}
       java.lang.Exception: cli: option notifier: expected optarg, got sym
                                ...
           boot.cli/assert-argspecs                           cli.clj:  195
                     boot.cli/clifn                           cli.clj:  207
                                ...
               clojure.core/load/fn                          core.clj: 5892
     clojure.core/load/invokeStatic                          core.clj: 5891
                  clojure.core/load                          core.clj: 5875
                                ...
 clojure.core/load-one/invokeStatic                          core.clj: 5696
              clojure.core/load-one                          core.clj: 5691
           clojure.core/load-lib/fn                          core.clj: 5736
 clojure.core/load-lib/invokeStatic                          core.clj: 5735
              clojure.core/load-lib                          core.clj: 5716
                                ...
    clojure.core/apply/invokeStatic                          core.clj:  647
clojure.core/load-libs/invokeStatic                          core.clj: 5773
             clojure.core/load-libs                          core.clj: 5757
                                ...
    clojure.core/apply/invokeStatic                          core.clj:  647
  clojure.core/require/invokeStatic                          core.clj: 5795
               clojure.core/require                          core.clj: 5795
                                ...
    boot.user/eval1889/invokeStatic  boot.user6798844399034494516.clj:   39
                 boot.user/eval1889  boot.user6798844399034494516.clj:   39
                                ...
                 boot.main/-main/fn                          main.clj:  177
                    boot.main/-main                          main.clj:  177
                                ...
                   boot.App.runBoot                          App.java:  390
                      boot.App.main                          App.java:  467
                                ...
                   boot.Loader.main                       Loader.java:  253

flyboarder00:12:28

@pleasetrythisathome: i caught that lastnight, it’s bug in the notify task

pleasetrythisathome00:12:43

also got a similar error about a task of mine

pleasetrythisathome00:12:47

clojure.lang.ExceptionInfo: cli: option start?: flags should not have optargs, got BOOL
    data: {:file "boot_component/reloaded.clj", :line 76}
       java.lang.Exception: cli: option start?: flags should not have optargs, got BOOL
                                ...
           boot.cli/assert-argspecs                           cli.clj:  196
                     boot.cli/clifn                           cli.clj:  207
                                ...
               clojure.core/load/fn                          core.clj: 5892
     clojure.core/load/invokeStatic                          core.clj: 5891
                  clojure.core/load                          core.clj: 5875
                                ...
 clojure.core/load-one/invokeStatic                          core.clj: 5696
              clojure.core/load-one                          core.clj: 5691
           clojure.core/load-lib/fn                          core.clj: 5736
 clojure.core/load-lib/invokeStatic                          core.clj: 5735
              clojure.core/load-lib                          core.clj: 5716
                                ...
    clojure.core/apply/invokeStatic                          core.clj:  647
clojure.core/load-libs/invokeStatic                          core.clj: 5773
             clojure.core/load-libs                          core.clj: 5757
                                ...
    clojure.core/apply/invokeStatic                          core.clj:  647
  clojure.core/require/invokeStatic                          core.clj: 5795
               clojure.core/require                          core.clj: 5795
                                ...
    boot.user/eval1889/invokeStatic  boot.user6508454767717565673.clj:   39
                 boot.user/eval1889  boot.user6508454767717565673.clj:   39
                                ...
                 boot.main/-main/fn                          main.clj:  177
                    boot.main/-main                          main.clj:  177
                                ...
                   boot.App.runBoot                          App.java:  390
                      boot.App.main                          App.java:  467
                                ...
                   boot.Loader.main                       Loader.java:  253

pleasetrythisathome00:12:25

do the task args actually cause an issue? it worked fine previously

flyboarder00:12:31

you may be missing the optarg placeholder

pleasetrythisathome00:12:33

seems like a negative regression to suddenly break tasks

flyboarder00:12:37

it does cause an issue on cli

flyboarder00:12:49

what your seeing is the validation working correctly

flyboarder00:12:35

the thread from yesterday goes over it

flyboarder00:12:59

yeah easy fix 😛

pleasetrythisathome00:12:12

might have been a little gentler to have it warn

pleasetrythisathome00:12:24

doesn't seem like something that should be crashing the entire task

flyboarder00:12:00

I thought so too but this is more of a task compilation error, those should probably terminate

pleasetrythisathome00:12:57

yea, just breaks a large amount of existing projects and requires library updates

pleasetrythisathome00:12:11

i've prefer not to have to fork everyone's lib just to get the build running again

pleasetrythisathome00:12:34

very common problem it seems

pleasetrythisathome00:12:37

boot-garden was it too

flyboarder00:12:31

mhm it seems widespread enough, @micha perhaps filling a missing optarg with _ would be appropriate

micha00:12:56

it's not really easy to know what the user meant there

micha00:12:50

if you compile a list of tasks i'll make pull requests to them with fixes

onetom01:12:20

@juhoteperi: i saw u forked zilti/boot-midje before it was better integrated with boot. are you using it? if not what issues have you faced? we tried 0.2.1-SNAPSHOT a bit in the past few days and it seems super fast and had no issues so far (unlike boot-test which is running slower and slower after every test run even with boot 2.5)

onetom01:12:14

im just asking because we would switch to it from clojure.test, but it seems it requires quite a bit of learning and shifting mindset, so i dont want to drag the team around testing frameworks too much. (my other candidates are expectations then speclj in that order, btw)

micha01:12:36

did you try just clojure.test without boot-test?

shwx8401:12:52

Hi, when running the commands listed in this section: https://github.com/boot-clj/boot#build-from-the-command-line , the generated .jar is missing "hello.txt".. Am I missing something?

micha01:12:11

oh yeah tthat section is wrong

micha01:12:15

i will update

shwx8401:12:50

ah, okay, thanks!

danielsz01:12:58

I'm trying to push to clojars with 2.5.0. The wiki says (push :repo-map {:username "user" :password "pass"}). But where do I specify that I want to push to clojars?

shwx8401:12:03

@micha: does that mean that I should always explicity add src/ to resource-paths to have it packaged in the jar?

micha01:12:14

@danielsz: the repo-map option takes a repository map, something like {:url "" :username "micha" :password "foop"}

shwx8401:12:39

alright, thanks!

micha01:12:46

that's the difference between :source-paths and :resource-paths

micha01:12:07

both are available on the classpath, but :source-paths aren't packaged in jars etc

danielsz01:12:48

@micha: You're my hero.

micha01:12:51

@danielsz: you can use the configure-repositories! function to configure credentials

micha01:12:16

that function can of course do whatever you want

micha01:12:56

boot.core/gpg-decrypt might be useful to you, as well

danielsz01:12:07

@micha: Oh cool. So that's used to not expose credentials.

danielsz01:12:15

in the repo map

micha01:12:28

yes basically

micha01:12:34

or if you have different repos for pushing

micha01:12:00

so you can push to a repo without adding it to the :repositories that wil be used for fetching as well

danielsz01:12:29

is configure-repositories! a top-level function in build.boot?

micha01:12:36

yes it's in boot.core

micha01:12:59

calling it with no args returns the current config function

micha01:12:08

so you can use that to wrap them if you want

danielsz01:12:22

and :repositories is an entry in the env?

micha01:12:59

the configure-repositories! function sets a callback

micha01:12:12

the callback is called whenever a repo is added to the :repositories map

micha01:12:21

i mean key

micha01:12:38

the callback takes a repo map as input and returns a new repo map

danielsz01:12:53

how does repositories and the push task :repo-map relate to each other?

micha01:12:03

they don't

micha01:12:17

the :repo-map option is to override :repositories

micha01:12:39

so push doesn't care about :repositories if you provide :repo-map

danielsz01:12:41

Ah, that's why I just pushed to clojars without :repositories

micha01:12:59

well clojars is part of the default repos

micha01:12:17

so unless you did (set-env! :repositories [] ... or something it would be in there

danielsz01:12:09

I did: (push :repo-map {:url "" :username "danielsz" :password "xxxxxxxxxx"})

micha01:12:31

so that would work even if you had removed everything from :repositories

micha01:12:44

because it has all the info it needs to push

danielsz01:12:13

Yes, but how do I refer to the pre-defined "clojars" in :repositories?

micha01:12:37

you don't want to use the :repo-map option then

danielsz01:12:59

Well, I need to get rid of the credentials, because the build.boot will be public

micha01:12:26

right, that's what you use the configure-repositories! function for

micha01:12:39

you can put that in your profile.boot

micha01:12:42

for example

micha01:12:53

or in a file named profile.boot in the project dir

micha01:12:59

if you want one per project

micha01:12:14

for example

danielsz01:12:17

@micha there was a PR earlier today around repo maps and strings, I believe.

danielsz01:12:55

I understood most of what you explained, one thing that evades me is how to refer to the pre-defined repositories (clojars). "clojars" -> {:url "https://clojars.org/repo/"}

danielsz01:12:21

Although that can wait.

danielsz01:12:45

I've had enough information to get going.

micha01:12:16

to refer to a predefined repository in the :repositories you mean?

micha01:12:25

you would use the :repo option for that, like before

micha01:12:59

what i pasted above is how you can store credentials in a gpg encrypted file

micha01:12:32

to push to clojars you'd do (push :repo "clojars" ...)

micha01:12:46

and that would look up "clojars" in the :repositories

danielsz01:12:49

@micha: works beautifully

danielsz01:12:05

@micha: leveraging the gpg binary was a winner

micha01:12:19

yeah i think so

micha01:12:42

now that i've set my gpg-agent timeout to like a billion years it works seamlessly for me simple_smile

danielsz01:12:11

Haha. @juhoteperi deserves a couple of beers, too. 🍻

micha01:12:19

many beers

danielsz01:12:52

@micha: nothing like a release to feel alive, right? I see you're helping out non-stop. I'm really impressed.

micha01:12:25

it's my pleasure!

micha01:12:19

the next big thing is getting some automated tests going

danielsz01:12:31

You have an idea of how to go about it already?

micha01:12:53

i added you to the boot-test org on github simple_smile

micha01:12:07

the idea is to fork public projects that build with boot there

micha01:12:14

and the test runner will build them

micha01:12:23

and make sure they don't break

donmullen01:12:24

@micha seems like some kind of test suite for community tasks would be helpful. So people have confidence that the boot tasks they are using are good to go with new releases.

micha01:12:34

yeah exactly

micha01:12:49

we could automate coverage and compat matrices this way

danielsz01:12:32

Sounds great.

micha01:12:02

end-to-end tests seem like the most economical way to go for now

micha01:12:35

unit tests probably don't give the same value per hour invested

micha01:12:50

especially since i'm committed to pushing bug fixes promptly

donmullen01:12:42

Agreed - I like your idea. Seems unlike the “I need this now - one-off - community tasks” would contain a bunch of unit tests.

danielsz02:12:08

@micha: I've tried to synthesize the information you've clarified in the wiki: https://github.com/boot-clj/boot/wiki/Deploying-with-Boot

micha02:12:10

@danielsz: thanks for writing that, it's great

danielsz02:12:19

@micha: Sure. One thing I was unclear about is if Boot will detect automatically the credentials.clj.gpg, and use it.

micha02:12:50

no, that was the original idea but it started getting complicated

micha02:12:04

so instead there is the general purpose callback that you can use to do anything you want

micha02:12:14

including decrypting a credentials file

micha02:12:19

or env vars

micha02:12:24

or any combination of whatever you want

micha02:12:36

i'll make a small change to the wiki page

danielsz02:12:36

@micha: That's great. I prefer it that way. So I'll clarify that.

micha02:12:48

ok cool, one sec

micha02:12:33

is there a tool to generate api docs as github markdown for clojure?

micha02:12:04

i think that's the way i'd like to generate api docs, and just commit to the repo instead of compiling html and deploying somewhere

alandipert02:12:19

(it's kind of cool more boot q's are showing up in SO! or maybe it's bad...)

danielsz02:12:15

@alandipert: Everything Is Illuminated!

danielsz02:12:32

I've started.

danielsz02:12:28

@micha: Cool, you've complemented important things that were missing. Awesome.

micha02:12:52

you can also have a profile.boot file in the project dir now

micha02:12:11

which could be useful if you want to have some per-project config, like maybe for push creds

micha02:12:25

you wouldn't want to commit that to git of course

danielsz02:12:43

Oh, very nice. That needs to go in the wiki too.

danielsz03:12:25

Nice. What's the caption? Something with light?

micha03:12:52

it's from one of william blake's illuminated manuscripts

micha03:12:41

god circumscribing creation with his compass

micha03:12:00

just like us

micha03:12:23

i want to know where the unit tests are

micha03:12:20

i wish people would not be looking so much for supported mechanisms

micha03:12:45

like if (System/getenv ...) does the thing, why not just use it?

micha03:12:22

man, i forgot how awesome the wiki is

micha03:12:46

it's amazing how much work everyone has put into it

danielsz03:12:57

You are the inspiration. Keep on rocking simple_smile

micha03:12:06

maybe we want a separate page to "managing maven repository credentials"?

micha03:12:38

or perhaps just add that to the title of the deploying page

micha03:12:25

Repository Credentials and Deploying with Boot

danielsz03:12:11

Sure. That makes it easier to spot the right page when you're looking for help with pushing.

danielsz03:12:26

The title I mean

danielsz03:12:47

I don't think a separate page is needed.

jethroksy04:12:48

I was just looking at @danielsz holy grail repo, and was wondering how I could interact with the repl with inf-clojure

micha04:12:03

you're in luck, he's here!

micha04:12:56

oh, i guess he signed off

micha04:12:56

are you already using inf-clojure with leiningen?

seancorfield04:12:07

Hey @micha ... With the Boot 2.5 release I thought I'd take another look ... I suspect we're too wedded to Leiningen plugins to switch but always interesting to see what others are up to.

micha04:12:51

sure, if you run into any trouble feel free to ask here

micha04:12:21

@jethroksy: do you start the repl process separately, or does inf-clojure do it for you?

jethroksy04:12:23

i tried boot repl-c

micha04:12:34

i think you want boot repl -s wait

jethroksy04:12:39

i created a defun

micha04:12:39

or just boot repl

micha04:12:02

inf-clojure doesn't use nrepl or anything, right?

micha04:12:08

it's just a clojure.main repl

jethroksy04:12:09

when i do just boot repl it starts the nrepl server but doesn't give me a prompt

jethroksy04:12:32

i'm sure there's support for nrepl somehow, because i see it when i use lein

jethroksy04:12:47

it says explicitly that it started a nrepl

jethroksy04:12:59

i'll try -s wait

micha04:12:04

if you do boot repl you'll get an interactive nrepl server and client connected to it

micha04:12:16

i.e. you can just start typing

jethroksy04:12:19

what if i just want a client

micha04:12:29

you mean just a server, no?

micha04:12:38

the client needs to connect to something

micha04:12:43

it's not useful on its own

jethroksy04:12:45

i want inf-clojure to connect to the server

jethroksy04:12:58

my intention is to make a deftask that comps everything

micha04:12:02

you can start just the server like this boot repl -s wait

jethroksy04:12:05

then just get inf-clojure to connect to it

micha04:12:16

you want to use the wait task there to prevent boot from exiting

jethroksy04:12:23

that's how @danielsz has it in his build.boot

micha04:12:27

because tasks generally don't block the pipeline

jethroksy04:12:31

`(boot :server true)

micha04:12:48

yeah he probably has the watch task in the pipeline

micha04:12:56

that would prevent boot from exiting also

jethroksy04:12:59

the server is up and running, but i wanna connect to it in inf-clojure

micha04:12:24

so boot will create the .nrepl-port file, emulating the thing that lein does

micha04:12:39

that's what most editor things use to figure out how to connect

micha04:12:02

if you already have a repl server running and you want to conect a client to it

micha04:12:08

you can do boot repl -c

micha04:12:26

that will also look for the .nrepl-port file if there is one, to figure out which port the server is listening on

micha04:12:46

or you can tell it which port boot repl -cp 12345

jethroksy04:12:01

boot doesn't randomize the ports right?

micha04:12:09

yeah it does

micha04:12:14

it gets any available port

jethroksy04:12:21

but can you specify the port in the server

micha04:12:41

boot repl -h will show all the options

jethroksy04:12:03

nice, because i get this error

jethroksy04:12:17

so i'm thinking just specify a fixed port to work around it

micha04:12:18

boot repl -sp 12345 wait would start a repl server on localhost:12345

jethroksy04:12:36

i'll try it and see if it works

micha04:12:14

looks promising

micha04:12:30

maybe you can put "boot repl" in there and it will just work

jethroksy04:12:39

yup i did something similar

micha04:12:25

the boot repl is pretty similar to the leiningen one

micha04:12:30

so that should work

jethroksy04:12:53

now this works

jethroksy04:12:02

could connect after specifying a port

jethroksy04:12:19

probably factor out the port number and make it an arg to run-boot-repl

micha04:12:31

you tried setting inf-clojure-program to "boot repl"?

jethroksy04:12:32

a pity it can't be automated for me, but it works simple_smile

micha04:12:50

cause then you wouldn't need to bother with ports or starting servers separately etc

seancorfield04:12:05

I gather from this discussion that there's no automated boot equivalent to cider-jack-in but you can manually start a REPL server and then cider-connect to it if you have the middleware setup correctly?

micha04:12:34

i think cider now is completely boot compatible

micha04:12:52

the hooks were added to cider to support boot projects

micha04:12:14

i'm a vi guy tho, so not totally up to date with cider

seancorfield04:12:16

How does it know whether to use lein or boot? (and good to know)

jethroksy04:12:20

yeah setq-ing to boot repl just works

micha04:12:50

if you could annotate the wiki with the trick that would be awesome too simple_smile

micha04:12:23

@seancorfield: it probably looks for project.clj or build.boot files

jethroksy04:12:29

i think the issue here is that boot doesn't get the correct classpath

jethroksy04:12:37

i mean inf-clojure

jethroksy04:12:59

if i run it from my buffr

jethroksy04:12:25

I don't run boot repl in the directory with my build.boot and that causes issues

micha04:12:45

oh, yeah you need to run it from the project directory

jethroksy04:12:21

i think starting the server and client separately is a little cleaner for me

micha04:12:36

boot isn't seeing your build.boot file, because there isn't one in the directory you're running it in

jethroksy04:12:37

this was supposed to be fixed in inf-clojure in the issue i posted earlier

micha04:12:48

so you're just getting a generic clojure repl there

micha04:12:55

your build.boot isn't being evaluated

jethroksy04:12:37

setq-ing boot repl doesn't just work

jethroksy04:12:04

I'll try to write something up for people who face issues anyway

micha04:12:26

are you running emacs from the project dir?

micha04:12:35

that might help

micha04:12:41

yeah that looks like it should work

micha04:12:53

you have a build.boot file, i assume?

micha04:12:07

haha ok just checking

jethroksy04:12:15

but the file i'm running inf-clojure from is deeply nested

jethroksy04:12:29

src/clj/holy_grail/handler.clj

micha04:12:59

is there a project.clj file in there somewhere?

micha04:12:19

cause that would confuse that project-root function

jethroksy04:12:19

i cloned the repo

micha04:12:38

which version of inf-clojure are you using?

jethroksy04:12:54

melpa's stable i think

micha04:12:07

i'm looking at the git tags

micha04:12:15

is that 1.3.0?

jethroksy04:12:57

inf-clojure-20151129.34

micha04:12:24

yeah that's old

micha04:12:39

if that's the date it was packaged, anyway

micha04:12:00

looks like you need at least version 1.1.0

jethroksy04:12:19

but this was just 18 days ago

micha04:12:24

hm wait maybe i'm confused

jethroksy04:12:39

looks like the last change was made 18 days ago too

micha04:12:53

can you run that locate-dominating-file function in a scratch buffer or something?

micha04:12:05

seems like it should find the project root correctly

seancorfield04:12:23

https://clojurians.slack.com/archives/boot/p1450327463003891 Indeed! I just read the CIDER source (on my phone -- groan!) and it looks for both files and asks you to choose if both are present. Very cool.

micha04:12:10

@seancorfield: i've been using vim fireplace with no issues for a while now, simple and good simple_smile

jethroksy04:12:29

@micha: i used to be a hardcore vim user too

seancorfield04:12:35

So cider-jack-in should just work in Emacs. Yay!

jethroksy04:12:36

really just switched to emacs because of clojure

jethroksy04:12:58

I'm just waiting for neovim to become more stable

seancorfield04:12:33

I can experiment with Boot without disturbing my colleagues by adding a build.boot and git-ignoring it :)

micha04:12:58

haha i won't tell anyone

seancorfield05:12:35

Ultimately I want to replace a big complex Ant "program" with Clojure and Leiningen doesn't seem geared to "file system operations" as much as Boot.

seancorfield05:12:39

Right now we do a lot of file system stuff in Ant and call out to lein to run Clojure processes which is icky.

micha05:12:00

yeah that's exactly what boot is made for simple_smile

micha05:12:51

you can also easily call out to lein from your boot program

micha05:12:05

in a pod, to isolate deps

micha05:12:23

i mean just calling the lein clojure functions, no need to shell out

micha05:12:22

also you can use lein plugins in boot if you make a little glue around the underlying implementation

micha05:12:38

before boot was fully bootstrapped with all the tasks we did that a lot

micha05:12:04

build a porject map for lein in boot task and callthe lein plugin implementation function

jethroksy05:12:56

I can't seem to get locate-dominating-file to return anything

jethroksy05:12:01

Gotta head out for a late lunch

jethroksy05:12:07

Will come back and retry!

micha05:12:21

great see ya

seancorfield05:12:45

@micha good to know that I can still use Leiningen plugins in Boot if I need to...

seancorfield05:12:54

I would imagine some of the more popular plugins are already available as Boot tasks? lein-expect perhaps? lein-localrepo?

micha05:12:45

pretty much yes

micha05:12:01

boot has all the things you need to work with clojure projects really

micha05:12:15

i mean we've been using it every day at work for over a year now

micha05:12:08

so all the things for dealing with maven, debugging dependencies, deploying to maven, building, compiling jvm languages, packaging, etc

micha05:12:30

all of that ships with boot

seancorfield05:12:13

Windows question: the boot.exe linked from the website is 2.4.2; running it seems to auto-update to 2.5.0 as expected. Is there a 2.5.0 .exe file?

micha05:12:44

not yet, but the exe file is very stable

micha05:12:03

it's just a java shell that bootstraps aether enough to fetch the rest of boot

micha05:12:26

you can use that exe file with any stable version of boot

micha05:12:36

from 2.0.0 to ...

micha05:12:22

we're going to release an update for it soon, but just with cosmetic fixes, like renaming the main class so it shows up as Boot in visualvm and osx process manager

jethroksy05:12:30

So the problem is with default-directory in emacs

jethroksy05:12:38

It seems that that's the way emacs behaves

jethroksy05:12:53

So there's no way around it that isn't hackish

micha05:12:59

default-directory is the fallback though

jethroksy05:12:05

It's my mistake for thinking it works like jack-in

micha05:12:26

i'd think it could find the root by the build.boot file and not get to default-directory

jethroksy05:12:49

The defun doesn't seem to work its way up

micha05:12:02

oh, ok my mistake

jethroksy05:12:26

I think it's meant to though...?

jethroksy05:12:43

I'll probably just change the implementation and see if it works

seancorfield05:12:09

I'm a bit surprised that src isn't a default source path...?

micha05:12:33

defaults like that aren't so helpful when the project is more complex though

micha05:12:48

it's harder to understand the build program when there are a lot of impleicit things

micha05:12:11

instead you can achieev these things via clojure functions in namespaces in libraries

micha05:12:37

for example we use bootlaces at adzerk

micha05:12:52

that sets up our environment for the way we like to do it

micha05:12:41

it includes src as a default :resource-paths, incidentally

micha05:12:18

that bootlaces library just composes built-in boot tasks and configures them in the way we like

micha05:12:36

but you might prefer something different

jethroksy05:12:30

i've seen this, but emacs must have it implemented somewhere if not the original code wouldn't work would it

jethroksy05:12:06

but based on the doc string it should work

micha05:12:44

i guess you could make a wrapper script

micha05:12:51

if worse comes to worst

jethroksy05:12:59

i made do with my custom defun

jethroksy06:12:37

In any case since its a reloaded workflow, I don't expect to be running the command over and over again simple_smile

jethroksy06:12:47

thanks anyway!

micha06:12:24

:thumbsup:

jethroksy06:12:25

it works in my new hoplon-castra project

jethroksy06:12:20

did a short write up, might wanna link it under the home page

micha06:12:29

awesome yeah

juhoteperi06:12:56

@onetom: No, I never got boot-midje working correctly.

seancorfield06:12:26

What's the equivalent to lein test?

seancorfield06:12:07

Ah, that wasn't listed on the Community Tasks page?

jethroksy06:12:16

not too sure

jethroksy06:12:45

oh it was made by adzerk

jethroksy06:12:51

so not "community"

seancorfield06:12:06

A subtle distinction simple_smile

micha06:12:10

it's still "community" we just forgot to add it to the list simple_smile

seancorfield06:12:42

Ah, I looked under T for Tests

seancorfield06:12:54

not under C for clojure.test runner

micha06:12:56

anyone can join the org and contribute, just tell me your github name simple_smile

seancorfield06:12:46

Hmm, I followed the instructions and got Could not locate boot_test.clj on the classpath, failing on (require '[adzerk/boot-test :refer :all])

micha06:12:28

you added the dependency?

jethroksy06:12:31

did you add the dep

seancorfield06:12:36

I saw it download the 1.0.6 JAR file yes.

seancorfield06:12:48

(So, yes, I followed the instructions simple_smile

juhoteperi06:12:59

You need . instead of / in the require

jethroksy06:12:09

ah right good catch haha

seancorfield06:12:29

Argh! copy'n'paste error!

jethroksy06:12:37

@micha: anything on the #C08BDAPRA side?

seancorfield06:12:47

(if we had karma here)

seancorfield06:12:29

OK, I'll consider that all a successful first experiment with Boot. I can use Clojure 1.8.0 RC 4, I can do the equivalent of lein run and lein test.

micha06:12:09

so far so good?

seancorfield06:12:21

What's the significance of with-pre-wrap?

seancorfield06:12:41

Seems like just returning identity achieves the same if you're not making changes?

micha06:12:47

the tasks are functions, but they're like stateful transducers, they have a certain "shape"

seancorfield06:12:51

(regarding equivalent of lein run)

micha06:12:34

the with-pre-wrap macro removes some boilerplate if you want to make middlewre that does its work before passing control to the next handler

seancorfield06:12:43

(with-pre-wrap fileset (my.namespace/-main) fileset) and (my.namespace/-main) identity seem equivalent as the body...

micha06:12:08

fileset there is an obkect

micha06:12:17

a clojure record type

micha06:12:24

identity would be a function, not the same

micha06:12:36

oh i see what you mean

micha06:12:12

that's the basic structure of a task

micha06:12:22

it looks a lot like ring middleware or transducers

seancorfield06:12:39

Thanks. Will read tomorrow I expect.

micha06:12:55

a little farther down in that page is the derivation of pre-wrap and post-wrap

micha06:12:04

i believe there are similar things for ring

micha06:12:24

like "do work before calling continuation" and "do work after calling continuation"

micha06:12:48

you can make macros to simplify these common patterns

micha06:12:18

the basic idea is similar to ring

micha06:12:40

but instead of a request map that's threaded through the middleware stack, it's this immutable fileset thing

micha06:12:24

the fileset is an immutable snapshot of the current state of the filesystem, as far as the JVM and boot are concerned

micha06:12:43

you can perform operations with pure functions on the fileset, and get a new fileset object

micha06:12:59

then you can call comit! on it and the underlying files will be updated

seancorfield06:12:07

Nice. Tomorrow I'll have to look at more complex tasks that manipulate the filesystem.

seancorfield07:12:34

One more question... it looks like the default behavior is to write to the target directory but there is a warning about that being deprecated and to use BOOT_EMIT_TARGET=no and the target task instead.

seancorfield07:12:17

But if I add that to boot.properties and do boot pom target, I can't find pom.xml afterward...

micha07:12:47

the target task expects an argument, like this

micha07:12:53

boot pom target -d target

micha07:12:15

the argument specifies the path of the directory to emit to

seancorfield07:12:28

But doesn't complain when the argument is omitted 😞

micha07:12:38

ah yeah, that's a bug

micha07:12:47

actually it could have a sane default

micha07:12:50

like "target"

micha07:12:17

probably release 2.5.1 tomorrow so i'll add that in

seancorfield07:12:19

and presumably the jar task takes an argument to override the name of the jar?

micha07:12:07

the problem with trying to name the jar by pom properties is that there may be multiple poms in the jar, or none at all

micha07:12:27

however 2.5.1 will have logic to do the expected thing if there is exactly one pom in the jar

seancorfield07:12:02

I can specify task-options! to default all these things... It's all just new stuff to learn simple_smile

micha07:12:06

task-options! is a macro that is just doing alter-var-root on the task vars

micha07:12:25

currying them, basically

micha07:12:49

but a function that takes kwargs only is curried in an interesting way

seancorfield07:12:04

Yeah, just saying that there are a bunch of things that are different to Leiningen that need to be taken into account.

seancorfield07:12:00

Nice that boot runs seamlessly in both Windows CMD and Git Bash (on Windows)... which Leiningen does not!

micha07:12:25

that's good news!

micha07:12:34

we're short on windows expertise

seancorfield07:12:39

(because it's lein.bat which only runs in Windows CMD -- and lein shell isn't compatible enough with Git Bash)

micha07:12:19

yeah i don't know enough about windows to make bat scripts, so launch4j it is

micha07:12:19

there is a boot.l4j.ini file you can use to set some properties to affect how l4j works, if you need to

seancorfield07:12:10

One thing that will be an issue for us is that we rely on dynamically setting JVM options for launching tasks in Leiningen (so it automatically adapts to different environments). We'd have to factor that out, rather than having it centralized in project.clj.

micha07:12:29

yeah you'd need a wrapper script

micha07:12:39

because boot runs in a single jvm

micha07:12:51

there is the BOOT_JVM_OPTIONS env var you can use

seancorfield07:12:54

We rely on dynamic evaluation inside project.clj quite a bit... which is probably naughty...

micha07:12:17

you could have boot launch another instance of boot i'm sure

seancorfield07:12:17

I know Phil rolls his eyes whenever we talk about how our build works!

micha07:12:25

haha i do that also

micha07:12:34

i mean i need to program, i'm a programmer

micha07:12:46

of course i am going to evaluate code in there simple_smile

seancorfield07:12:07

We have a Leiningen plugin that copies everything from the classpath to a specified directory, for example. Because reasons. ahem

seancorfield07:12:18

Oh that makes me feel less evil!

micha07:12:58

we can't build boot with boot yet, because we can't figure out how to compile a clojure namespace while another version of it is already loaded in memory

seancorfield07:12:19

OK. Time to turn in. I'll be back with more questions tomorrow I'm sure. Thank you very much for being so responsive @micha!

micha07:12:34

sure, it's my pleasure

danielsz12:12:29

Good morning, everybody!

danielsz12:12:45

What a glorious day for a 2.5.1 release!

danielsz12:12:24

@martinklepsch: @micha said something of a 2.5.1 release today. I'm not even making things up. simple_smile

danielsz12:12:01

@martinklepsch: Do you run Boot from the master branch or stable releases?

martinklepsch12:12:10

mostly stable releases

martinklepsch12:12:45

boot version is pinned project wide so everyone uses the same version

danielsz12:12:43

@martinklepsch: Not sure I understand. You can run Boot from the master branch and have all the latest commits, no?

martinklepsch12:12:05

@danielsz: In projects I work on w/ other people we have a boot.properties if I'd want to run master I would need to override my existing maven jars with never ones which seems like asking for trouble to me simple_smile

martinklepsch12:12:50

I occasionally just edit boot.properties to use a snapshot build if I want to do some testing

martinklepsch12:12:53

I probably would use "master" more if we'd have snapshots on clojars simple_smile

danielsz12:12:05

Ah, yeah, if you work in a team, you have to look out for those things. Ah, snapshot builds, yeah, that's something I'd do before compiling the jars from master myself.

danielsz12:12:23

So where are the snapshots?

danielsz12:12:04

I've never used the snapshots, only compiled from master.

danielsz13:12:17

You have to download them from github directly, they don't get uploaded to clojars?

juhoteperi13:12:59

2.5.0-SNAPSHOT was deployed to clojars

alandipert13:12:44

i'm not sure the latest 2.5.0-SNAPSHOT on clojars is viable... micha mentioned something about corrupt metadata.xml

alandipert13:12:30

we hope to get it resolved and do more snapshotting in the future

alandipert13:12:50

(it would have been good to have made a 2.5.0-snapshot available prior to 2.5 release)

danielsz13:12:27

@alandipert: +1 for snapshots as a vehicle for testing new features and fixes, as compiling from the master branch looks more involved and less appealing.

alandipert13:12:43

ideally we get the thing on CI and every push creates a snapshot

alandipert13:12:55

i will do this today

alandipert13:12:14

if i can figure out the xml nastybusiness, anyway

magomimmo14:12:41

hi all, I just published a new tutorial of the modern-cljs series (https://github.com/magomimmo/modern-cljs) which now uses boot and related community based task instead of leiningen/cljsbuild. This tutorial try to build a TDD environment with a CLJ and CLJS REPLs as well. It uses, with some shortcoming, both boot-test and boot-cljs-test tasks on portable .cljc files/namespaces. Hopefully someone will find it useful. Here is the link: (https://github.com/magomimmo/modern-cljs/blob/master/doc/second-edition/tutorial-16.md)

juhoteperi14:12:59

@magomimmo: With super quick glance, I can see one bad habit there: (serve :dir "target")

martinklepsch14:12:11

If you prefer (like I do) the colon separated directories mode, you have to parse the passed argument by yourself.

martinklepsch14:12:19

I think that's not quite true?

juhoteperi14:12:21

It's much preferred to serve files from classpath than from target dir (especially with boot 2.5.0, which doesn't by default write to target dir)

martinklepsch14:12:44

@juhoteperi: boot 2.5.0 still writes to target by default

juhoteperi14:12:15

Hmm yeah, if user has not set the env var

magomimmo14:12:27

what’s is the right thing to do instead of (serve ;dir target)

tcrawley14:12:47

alandipert: are you referring to the maven-metadata.xml for boot/worker? that should be fixed now: https://github.com/clojars/clojars-web/issues/440

juhoteperi14:12:54

(serve :resource-root "") serves the whole classpath

juhoteperi14:12:10

That is, files in fileset with input role (not maybe completely correct)

magomimmo14:12:23

I used both of them

alandipert14:12:22

@tcrawley: oh thanks! i'll confirm w/ micha when he gets in

magomimmo14:12:27

@martinklepsch: how would you use the task DSL to have one argument only?

juhoteperi14:12:12

@magomimmo: I don't think it makes sense to provide both options, IIRC they are exclusive

magomimmo14:12:02

@juhoteperi: I’ll try to remove it and see what happens

martinklepsch14:12:26

@magomimmo: I think I confused this with kw options

juhoteperi14:12:33

Looks like I'm wrong, boot-http will first use ring handler if set, then files from dir if it set, then from classpath if resource-root is set

martinklepsch14:12:16

@magomimmo: when I was seeing the : I was thinking of that but that can't be used for sequences of undefined length

martinklepsch14:12:54

@magomimmo: I will think next time before I write 😛

magomimmo14:12:35

@martinklepsch: that’s casued by slack simple_smile

martinklepsch14:12:36

@magomimmo: is add-source-paths an exercise for the reader? because there is boot --source-paths

magomimmo14:12:05

it’s used to add test-dirs to source-paths

magomimmo14:12:59

@martinklepsch: yes, it’s used to add test-dirs to source-paths for the tdd task only

danielsz14:12:32

Ha, been burnt again when building a jar (source library, not uberjar). Files were missing. I forgot to add resource-paths (with same value as source-paths). I wonder how many times this happens to users. I bet many. There's a semantic grey zone here.

martinklepsch14:12:05

@danielsz: are you not using bootlaces? 😛

danielsz14:12:52

@martinklepsch: I was, and you're right, with bootlaces it was OK (forgot why). But now with the built-in push task, no need for bootlaces. (BTW, if this was meant as a joke, I missed it, sorry). I like the build.boot that you get now, very succinct and elegant: https://www.refheap.com/112812

martinklepsch14:12:52

although wasn't there always a push task? (I almost always just used bootlaces)

juhoteperi14:12:48

Push has been built-in but Bootlaces used to be necessary for reading clojars creds from env

juhoteperi14:12:10

Now it's quite easy to set Clojars creds without Bootlaces

alqvist14:12:26

I have a problem with "Invalid cross-device link" and uberjar. I think it started after 2.5

alqvist14:12:36

home and root is on different devices

alqvist14:12:49

.boot and .m2 is in home

martinklepsch14:12:53

I'll need to give the new gpg stuff a go simple_smile

alqvist14:12:11

The traceback is referencing /tmp/....

danielsz14:12:03

@alqvist: I don't know what that means, but I can tell you something else. You can use :dependencies '[[boot-environ "1.0.1"]] instead of danielsz/boot-environ

danielsz14:12:58

The environ project has boot support now.

alandipert14:12:48

@alqvist: boot makes lots of hardlinks to do the structural sharing thing, you should set BOOT_HOME to somewhere on the device your project is on

alandipert14:12:53

(default is ~/.boot)

alandipert14:12:03

(it's still ok for m2 to be on home device, but you could make it live elsewhere with BOOT_LOCAL_REPO if you wanted. end of boot -h shows all configs)

alqvist14:12:04

@danielsz: Thanks, I have changed my deps

alqvist14:12:40

@alandipert: My project is on ~/git/projectname

alqvist14:12:05

@alandipert: And I had no custom BOOT_HOME

alqvist14:12:50

@alandipert: Same problem though if I do export BOOT_HOME=/home/andreas/.boot/ and export BOOT_LOCAL_REPO=/home/andreas/.m2/repository

micha15:12:58

@alqvist: BOOT_HOME needs to be on the same physical device as your project

alqvist15:12:23

@micha: I have my projectdir, .m2 and .boot all on the same device(home)

micha15:12:09

and you still get cross device link errors?

alqvist15:12:03

@micha: yes. Pretty sure it worked before 2.5

martinklepsch15:12:27

@alqvist: maybe good to test with 2.4.2 just to make sure?

alqvist15:12:14

@martinklepsch: yea, will do. There might have been something else that broke it

alqvist15:12:58

@martinklepsch:2.4.2 works without any problem

martinklepsch16:12:38

@alqvist: please share the complete stacktrace if possible

alqvist16:12:45

@martinklepsch: I have update the issue with a complete traceback

pandeiro17:12:34

should setting BOOT_CLOJURE_VERSION=1.8.0-RC4 in boot.properties work?

micha17:12:10

@pandeiro: yep, does it not?

pandeiro17:12:28

we were getting a 254 here

pandeiro17:12:30

and no output

pandeiro17:12:40

since changing that value from 1.7.0

micha17:12:54

what do you mean 254?

flyboarder18:12:18

I remember someone mentioning a deps.edn file that grabs new deps when it gets updated, does this task already exist or am I out to lunch?

micha18:12:26

version 2.5.1-SNAPSHOT is available

micha18:12:57

to use it you can set BOOT_VERSION=2.5.1-SNAPSHOT in your /.boot/boot.properties file

micha18:12:27

and then just do boot and it'll install everything

micha18:12:47

feedback before pushing 2.5.1 release is very welcome

flyboarder18:12:47

@micha: first run with 2.5.1-SNAPSHOT no issues, projects building simple_smile

micha18:12:27

whew! thanks!

micha18:12:45

i removed the exceptions when deftask doesn't parse by the way

micha18:12:49

now it just warns

flyboarder19:12:50

oh cool, @pleasetrythisathome that should fix the issue of you needing to fork the notify and garden tasks

micha19:12:04

i submitted PR for notify anyway

flyboarder19:12:19

should the BOOT_EMIT_TARGET warning get turned off when the option is set

micha19:12:20

and martin already fixed garden

micha19:12:41

is it set to no?

flyboarder19:12:54

it’s set to ’no'

micha19:12:23

oh that was another bugfix in 2.5.1, that warning now says it without the quotes simple_smile

micha19:12:40

if you remove the quotes it'll work

flyboarder19:12:07

but with quotes worked too for a custom target dir?

flyboarder19:12:20

the message went away now 😛

martinklepsch20:12:41

@micha: Whats the scratch stuff? Is that documented somewhere?

micha20:12:40

@martinklepsch: the tmpdir library needs to make temp directories for staging certain changes

micha20:12:05

it's not documented because it's an implementation detail

micha20:12:57

like for instance when the merge strategies are applied (like for uber for example) it needs to stage its changes in a directory because the merges need to be applied in order

micha20:12:23

then it imports them into the blob storage in one batch operation from the staging dir

seancorfield20:12:49

I'm playing around trying to get Expectations running with Boot. I can trigger it easily enough but I can't figure out how to require the test namespaces. Is there something built into Boot to make it easy to get namespaces from, say, the test folder tree so I can require them?

martinklepsch20:12:37

@seancorfield: it only needs to be in source-paths

seancorfield20:12:12

The test namespaces did not show up in (all-ns) tho' when I did that...

micha20:12:12

i think (all-ns) only shows loaded namespaces

micha20:12:48

if you want to scan the classpath for all namespaces including ones that clojure doesn't yet know about you can use tools.namespace

seancorfield20:12:19

Yeah, I was looking at that and hoping to do something simpler -- silly me simple_smile

micha20:12:51

seems like something we could add to boot.pod namespace

micha20:12:02

with the rest of the classpath utilities

seancorfield20:12:49

Feedback, simplifications, improvements welcome!

flyboarder21:12:06

@seancorfield: is there a repo I can track this at?

seancorfield21:12:31

Not yet. I will publish it once I have it a bit more polished.

seancorfield21:12:53

For now I'm just scratching around trying to learn Boot simple_smile

martinklepsch21:12:00

@seancorfield: could you use just 'sym instead of (symbol "sym")?

seancorfield21:12:25

Yeah, I'd like to avoid the resolve too...

martinklepsch21:12:45

Maybe I'd move the resolve stuff into a let binding for better readability

martinklepsch21:12:26

not sure if that's possible to avoid entirely when requiring at runtime

seancorfield21:12:31

If I use pods...? boot-test doesn't seem to need the resolve calls...

martinklepsch21:12:47

Maybe you're right

seancorfield21:12:36

I'll probably copy boot-test and modify it to run Expectations instead instead of trying to figure out the pod stuff from scratch.

seancorfield21:12:54

Now that I have the basic Expectations stuff working, that is simple_smile

alandipert21:12:35

@seancorfield: i answered a question on SO earlier that contains a minimal pod usage that might be educational, https://stackoverflow.com/questions/33982533/clojure-boot-repl-in-a-particular-namespace - under "build.boot with automatic reloading"

seancorfield21:12:26

@alandipert: in that code you have (with-pre-wrap [fileset] ... fileset) but other examples I've seen don't have the [ ] -- any reason for that?

alandipert21:12:48

@seancorfield: they both work and do the same thing... we addded the vector version later because it was more natural for some

seancorfield21:12:53

Yeah, using pods let me omit the resolve calls. Thank you!

seancorfield21:12:53

This also throws an exception on failure so the build fails with a non-zero exit code.

seancorfield21:12:16

Runs a fair bit slower with pods (no surprise I guess) but the code is cleaner -- albeit a bit more complicated.

micha21:12:46

pods allow you to run your tests in a fresh clojure environment each time

micha21:12:56

so you don't have issues with stale state in namespaces

micha21:12:15

however it does take a second or two to compile clojure core and whatnot

micha21:12:56

you can mitigate this by using the pod-pool function which creates a pool of pods you can use, and they'll be warmed up asynchronously with clojuare already compiled and loaded

micha21:12:52

you can set the size of the pool to accomodate your peak usage, like if you are reloading more often you want to have a larget pool

seancorfield22:12:48

Nice that I don't need anything special to auto-run tests... boot watch expectations...

seancorfield22:12:13

Question for @alandipert and @micha -- is that simple Expectations task "enough" or do I need to do more of the pod stuff that boot-test does in order to take advantage of pods properly?

seancorfield22:12:38

(i.e., what am I losing by not doing all that cleanup / shutdown stuff etc?)

micha22:12:05

one thing you can do is perhaps require expectations and ctnf in the pod pool init phase

micha22:12:16

that would load those namespaces into the pod asynchronously

micha22:12:26

and speed things up a bit potentially

martinklepsch22:12:48

@micha: is the cleanup stuff in boot-test actually required? what does this line do? https://github.com/adzerk-oss/boot-test/blob/master/src/adzerk/boot_test.clj#L55

martinklepsch22:12:12

it seems to shutdown the pool at task-creation time?

micha22:12:18

that shuts down the pod pool when the boot pipeline finishes

micha22:12:39

like for example suppose you do (boot (watch) (test)) in the repl

martinklepsch22:12:43

oh, core/cleanup registers something to be called at the end?

micha22:12:49

and you change things, and it tests and so on

micha22:12:57

when the boot pipeline exits

micha22:12:18

this is useful in the repl because the jvm survives

micha22:12:26

and you could start a new pipeline

micha22:12:48

so like if you have a web server task, you want to shut the webserver down in the cleanup clause

micha22:12:20

otherwise when you run the pipeline again you'll get address not available errors because the old webserver was never shut down and it's runnig in another thread

micha22:12:04

so @seancorfield if you don't perform cleanup in your task you may run into resource issues if you run your task repeatedly in the repl

micha22:12:45

the cleanup macro is equivalennt to the stop lifecycle of a Component thing

seancorfield22:12:59

Interestingly you can't require Expectations like that -- you get a ClassNoDefFound exception on clojure.core/ns_interns$fn... at the end. Still, I can require http://java.io / tools.namespace async tho'...

danielsz23:12:56

To whom it may concern: boot-runit was broken with the 2.5.0 release. This is now fixed in boot-runit 0.0.1-SNAPSHOT.