This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-12-17
Channels
- # admin-announcements (104)
- # adventofcode (3)
- # aws (1)
- # boot (651)
- # cljs-dev (21)
- # cljsrn (12)
- # clojure (81)
- # clojure-china (1)
- # clojure-germany (1)
- # clojure-miami (2)
- # clojure-nl (8)
- # clojure-russia (19)
- # clojurescript (208)
- # core-typed (1)
- # cursive (19)
- # datavis (55)
- # datomic (57)
- # events (1)
- # hoplon (102)
- # ldnclj (12)
- # leiningen (8)
- # off-topic (11)
- # om (127)
- # onyx (21)
- # parinfer (2)
- # portland-or (3)
- # proton (2)
- # re-frame (2)
- # reagent (6)
seems like boot 2.5.0 is breaking some boot tasks
getting cli errors
java.lang.Exception: cli: option notifier: expected optarg, got sym
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
@pleasetrythisathome: i caught that lastnight, it’s bug in the notify task
also got a similar error about a task of mine
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
do the task args actually cause an issue? it worked fine previously
you may be missing the optarg placeholder
seems like a negative regression to suddenly break tasks
it does cause an issue on cli
what your seeing is the validation working correctly
the thread from yesterday goes over it
ah cool
makes sense
yeah easy fix 😛
might have been a little gentler to have it warn
doesn't seem like something that should be crashing the entire task
I thought so too but this is more of a task compilation error, those should probably terminate
yea, just breaks a large amount of existing projects and requires library updates
i've prefer not to have to fork everyone's lib just to get the build running again
very common problem it seems
boot-garden was it too
mhm it seems widespread enough, @micha perhaps filling a missing optarg with _
would be appropriate
@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)
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)
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?
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?
@micha: does that mean that I should always explicity add src/ to resource-paths to have it packaged in the jar?
@danielsz: the repo-map
option takes a repository map, something like {:url "
so you can push to a repo without adding it to the :repositories
that wil be used for fetching as well
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/"}
now that i've set my gpg-agent timeout to like a billion years it works seamlessly for me
Haha. @juhoteperi deserves a couple of beers, too. 🍻
@micha: nothing like a release to feel alive, right? I see you're helping out non-stop. I'm really impressed.
@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.
Agreed - I like your idea. Seems unlike the “I need this now - one-off - community tasks” would contain a bunch of unit tests.
@micha: I've tried to synthesize the information you've clarified in the wiki: https://github.com/boot-clj/boot/wiki/Deploying-with-Boot
@micha: Sure. One thing I was unclear about is if Boot will detect automatically the credentials.clj.gpg, and use it.
so instead there is the general purpose callback that you can use to do anything you want
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
it would be cool of someone to illuminate this dude - http://stackoverflow.com/questions/34017732/using-gpg-encrypted-credentials-or-specific-environment-variables-with-boot-cl
(it's kind of cool more boot q's are showing up in SO! or maybe it's bad...)
@alandipert: Everything Is Illuminated!
which could be useful if you want to have some per-project config, like maybe for push creds
Illuminating one soul at a time: http://stackoverflow.com/questions/34017732/using-gpg-encrypted-credentials-or-specific-environment-variables-with-boot-cl/34325828#34325828
Edited the Wiki: https://github.com/boot-clj/boot/wiki/Configuring-Boot#configuring-your-project
Sure. That makes it easier to spot the right page when you're looking for help with pushing.
made a few updates here: https://github.com/boot-clj/boot/wiki/Configuring-Boot
hi @seancorfield, welcome!
I was just looking at @danielsz holy grail repo, and was wondering how I could interact with the repl with inf-clojure
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.
@jethroksy: do you start the repl process separately, or does inf-clojure do it for you?
that will also look for the .nrepl-port
file if there is one, to figure out which port the server is listening on
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?
How does it know whether to use lein or boot? (and good to know)
@jethroksy: great!
@seancorfield: it probably looks for project.clj
or build.boot
files
boot isn't seeing your build.boot file, because there isn't one in the directory you're running it in
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.
@seancorfield: i've been using vim fireplace with no issues for a while now, simple and good
So cider-jack-in
should just work in Emacs. Yay!
I can experiment with Boot without disturbing my colleagues by adding a build.boot
and git-ignoring it :)
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.
Right now we do a lot of file system stuff in Ant and call out to lein to run Clojure processes which is icky.
also you can use lein plugins in boot if you make a little glue around the underlying implementation
build a porject map for lein in boot task and callthe lein plugin implementation function
the boot-beanstalk task is an example of that: https://github.com/adzerk-oss/boot-beanstalk/blob/master/src/adzerk/boot_beanstalk/impl.clj
@micha good to know that I can still use Leiningen plugins in Boot if I need to...
I would imagine some of the more popular plugins are already available as Boot tasks? lein-expect perhaps? lein-localrepo?
so all the things for dealing with maven, debugging dependencies, deploying to maven, building, compiling jvm languages, packaging, etc
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?
Thanks.
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
i'd think it could find the root by the build.boot file and not get to default-directory
I'm a bit surprised that src
isn't a default source path...?
that bootlaces library just composes built-in boot tasks and configures them in the way we like
i've seen this, but emacs must have it implemented somewhere if not the original code wouldn't work would it
In any case since its a reloaded workflow, I don't expect to be running the command over and over again
@onetom: No, I never got boot-midje working correctly.
What's the equivalent to lein test
?
Ah, that wasn't listed on the Community Tasks page?
A subtle distinction
Ah, I looked under T for Tests
not under C for clojure.test runner
Hmm, I followed the instructions and got Could not locate boot_test.clj on the classpath, failing on (require '[adzerk/boot-test :refer :all])
I saw it download the 1.0.6 JAR file yes.
(So, yes, I followed the instructions
You need .
instead of /
in the require
Argh! copy'n'paste error!
(if we had karma here)
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
.
What's the significance of with-pre-wrap
?
Seems like just returning identity
achieves the same if you're not making changes?
the tasks are functions, but they're like stateful transducers, they have a certain "shape"
(regarding equivalent of lein run
)
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
(with-pre-wrap fileset (my.namespace/-main) fileset)
and (my.namespace/-main) identity
seem equivalent as the body...
...of a task.
Thanks. Will read tomorrow I expect.
but instead of a request map that's threaded through the middleware stack, it's this immutable fileset thing
the fileset is an immutable snapshot of the current state of the filesystem, as far as the JVM and boot are concerned
you can perform operations with pure functions on the fileset, and get a new fileset object
Nice. Tomorrow I'll have to look at more complex tasks that manipulate the filesystem.
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.
But if I add that to boot.properties
and do boot pom target
, I can't find pom.xml
afterward...
But doesn't complain when the argument is omitted 😞
and presumably the jar
task takes an argument to override the name of the jar?
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
understood
however 2.5.1 will have logic to do the expected thing if there is exactly one pom in the jar
I can specify task-options!
to default all these things... It's all just new stuff to learn
Yeah, just saying that there are a bunch of things that are different to Leiningen that need to be taken into account.
Nice that boot
runs seamlessly in both Windows CMD and Git Bash (on Windows)... which Leiningen does not!
(because it's lein.bat
which only runs in Windows CMD -- and lein
shell isn't compatible enough with Git Bash)
there is a boot.l4j.ini file you can use to set some properties to affect how l4j works, if you need to
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
.
We rely on dynamic evaluation inside project.clj
quite a bit... which is probably naughty...
I know Phil rolls his eyes whenever we talk about how our build works!
We have a Leiningen plugin that copies everything from the classpath to a specified directory, for example. Because reasons. ahem
Oh that makes me feel less evil!
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
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!
Can't wait to try out https://github.com/boot-clj/boot/commit/44f9b8989310e6c30356f0455c97abe689f6b47c
@martinklepsch: @micha said something of a 2.5.1 release today. I'm not even making things up.
I know
@martinklepsch: Do you run Boot from the master branch or stable releases?
mostly stable releases
boot version is pinned project wide so everyone uses the same version
@martinklepsch: Not sure I understand. You can run Boot from the master branch and have all the latest commits, no?
@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
I occasionally just edit boot.properties to use a snapshot build if I want to do some testing
I probably would use "master" more if we'd have snapshots on clojars
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.
2.5.0-SNAPSHOT was deployed to clojars
i'm not sure the latest 2.5.0-SNAPSHOT on clojars is viable... micha mentioned something about corrupt metadata.xml
we hope to get it resolved and do more snapshotting in the future
(it would have been good to have made a 2.5.0-snapshot available prior to 2.5 release)
@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.
ideally we get the thing on CI and every push creates a snapshot
i will do this today
if i can figure out the xml nastybusiness, anyway
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)
Awesome, @magomimmo.
@magomimmo: With super quick glance, I can see one bad habit there: (serve :dir "target")
If you prefer (like I do) the colon separated directories mode, you have to parse the passed argument by yourself.
I think that's not quite true?
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)
@juhoteperi: boot 2.5.0 still writes to target by default
Hmm yeah, if user has not set the env var
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
(serve :resource-root "")
serves the whole classpath
That is, files in fileset with input role (not maybe completely correct)
@tcrawley: oh thanks! i'll confirm w/ micha when he gets in
@martinklepsch: how would you use the task DSL to have one argument only?
@magomimmo: I don't think it makes sense to provide both options, IIRC they are exclusive
@juhoteperi: I’ll try to remove it and see what happens
@magomimmo: I think I confused this with kw options
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
@magomimmo: https://github.com/boot-clj/boot/wiki/Task-Options-DSL#complex-options
@magomimmo: when I was seeing the :
I was thinking of that but that can't be used for sequences of undefined length
@magomimmo: I will think next time before I write 😛
@martinklepsch: that’s casued by slack
@magomimmo: is add-source-paths
an exercise for the reader? because there is boot --source-paths
@martinklepsch: yes, it’s used to add test-dirs to source-paths for the tdd task only
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.
@danielsz: are you not using bootlaces? 😛
@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
although wasn't there always a push task? (I almost always just used bootlaces)
Push has been built-in but Bootlaces used to be necessary for reading clojars creds from env
Now it's quite easy to set Clojars creds without Bootlaces
I have a problem with "Invalid cross-device link" and uberjar. I think it started after 2.5
I'll need to give the new gpg stuff a go
@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
@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
(default is ~/.boot)
(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)
@alandipert: My project is on ~/git/projectname
@alandipert: And I had no custom BOOT_HOME
@alandipert: Same problem though if I do export BOOT_HOME=/home/andreas/.boot/
and export BOOT_LOCAL_REPO=/home/andreas/.m2/repository
@alqvist: maybe good to test with 2.4.2 just to make sure?
@martinklepsch: yea, will do. There might have been something else that broke it
@martinklepsch:2.4.2 works without any problem
@alqvist: please share the complete stacktrace if possible
@martinklepsch: I have update the issue with a complete traceback
This worked fine for me last night (on Windows 10): https://clojurians.slack.com/archives/boot/p1450373074004232
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?
@micha: first run with 2.5.1-SNAPSHOT
no issues, projects building
oh cool, @pleasetrythisathome that should fix the issue of you needing to fork the notify and garden tasks
should the BOOT_EMIT_TARGET
warning get turned off when the option is set
it’s set to ’no'
but with quotes worked too for a custom target dir?
weird
the message went away now 😛
all is well
awesome guys
@micha: Whats the scratch stuff? Is that documented somewhere?
@martinklepsch: the tmpdir library needs to make temp directories for staging certain changes
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
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?
@seancorfield: it only needs to be in source-paths
The test namespaces did not show up in (all-ns)
tho' when I did that...
if you want to scan the classpath for all namespaces including ones that clojure doesn't yet know about you can use tools.namespace
boot-test does it: https://github.com/adzerk-oss/boot-test/blob/master/src/adzerk/boot_test.clj#L15-L21
Yeah, I was looking at that and hoping to do something simpler -- silly me
Success!
Feedback, simplifications, improvements welcome!
@seancorfield: is there a repo I can track this at?
Not yet. I will publish it once I have it a bit more polished.
For now I'm just scratching around trying to learn Boot
@seancorfield: could you use just 'sym
instead of (symbol "sym")
?
Yeah, I'd like to avoid the resolve
too...
Maybe I'd move the resolve stuff into a let binding for better readability
not sure if that's possible to avoid entirely when requiring at runtime
If I use pods...? boot-test doesn't seem to need the resolve
calls...
Maybe you're right
I'll probably copy boot-test and modify it to run Expectations instead instead of trying to figure out the pod stuff from scratch.
Now that I have the basic Expectations stuff working, that is
@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"
@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?
@seancorfield: they both work and do the same thing... we addded the vector version later because it was more natural for some
'kthx
Yeah, using pods let me omit the resolve
calls. Thank you!
Here's my updated task https://www.refheap.com/112827
This also throws an exception on failure so the build fails with a non-zero exit code.
Runs a fair bit slower with pods (no surprise I guess) but the code is cleaner -- albeit a bit more complicated.
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
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
Nice that I don't need anything special to auto-run tests... boot watch expectations
...
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?
(i.e., what am I losing by not doing all that cleanup / shutdown stuff etc?)
one thing you can do is perhaps require
expectations and ctnf in the pod pool init phase
@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
it seems to shutdown the pool at task-creation time?
oh, core/cleanup registers something to be called at the end?
got it, thx
so like if you have a web server task, you want to shut the webserver down in the cleanup
clause
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
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
@seancorfield: something like this maybe https://www.refheap.com/112829
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'...