This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-11-13
Channels
- # beginners (71)
- # boot (61)
- # clara (49)
- # cljs-dev (9)
- # cljsjs (2)
- # cljsrn (5)
- # clojure (55)
- # clojure-android (1)
- # clojure-italy (4)
- # clojure-spec (39)
- # clojure-uk (56)
- # clojurescript (69)
- # cursive (5)
- # data-science (1)
- # defnpodcast (6)
- # devcards (1)
- # duct (12)
- # figwheel (3)
- # fulcro (18)
- # leiningen (35)
- # lumo (19)
- # midje (1)
- # off-topic (22)
- # om (3)
- # onyx (23)
- # portkey (3)
- # re-frame (20)
- # reagent (23)
- # ring-swagger (6)
- # shadow-cljs (119)
- # specter (7)
- # unrepl (25)
[seancorfield/boot-tools-deps "0.1.1"]
-- https://github.com/seancorfield/boot-tools-deps -- a Boot task to read deps.edn
files using tools.deps.alpha
so you can specify your dependencies externally and use both the clj
script and Boot with them. Feedback welcome!
I'm unsure if this should be a task, as it just modifies Boot state and does nothing with fileset
True. I wasn't really sure what the most idiomatic structure would be. I figured you might use it in a pipeline tho' boot deps ... my-task
@U061V0GG2 I suppose it could read the fileset to find the deps.edn file?
Oh, tools.deps.alpha has equivalents to :source-dir
, etc.? Maybe less interesting in that case.
Yeah, at first I was only thinking about getting dependencies from deps.edn
, and then I figured having all the :extra-deps
and :override-deps
stuff would be handy, and by that point it was easy to handle :paths
and :extra-paths
from the classpath side... and so it mapped to :resource-paths
and :source-paths
fairly neatly.
I don't know about that part much. I supsect a task isn't what you want, and what you want is a function, equivalent to set-env!/merge-env!
Except you want to be able to run it via boot deps repl
, for example. No need for a build.boot
file (since it can get dependencies and paths from deps.edn
).
I just pushed 0.1.2 which exposes the task logic as a load-deps
function for programmatic use. It still exposes the deps
task for convenience from the command line. Thanks for the feedback so far!
If your dependencies are in deps.edn
, that won't work. That's the whole point of this.
I don't think many people have a need for conditional loading of dependencies. "Standard" projects only use set-env!
, it's not considered common enough for there to be a built-in set-env-task!
.
Well, we have a separate deps.edn
file for each subproject and our build.boot
is in a different folder 🙂
That's kinda what happens when you have 50,000+ lines of production Clojure code spread across a dozen separate applications that also share a lot of code and infrastructure...
And maybe I'm unusual but I use boot
a lot from the command line without build.boot
files.
We're moving towards that too, and we have a dev
task which loads in tools.namespace for example. So I definitely know we needed it too!
If it's repl only, then I'm on the fence about it tbh. People use set-env!
from the repl to load additional dependencies, for example.
Meh, I prefer automation... and if I'm already using deps.edn
but want the flexibility of a Boot REPL, doing boot -d seancorfield/boot-tools-deps deps repl
gives me all the power of Boot and compatibility with clj
🙂 Like I say, I'm probably unusual in how I use boot
without build.boot
...
For sure. I like the flexibility, I've definitely written this several times, so I'm glad for it. Not campaigning for removal.
I don’t see an obvious way here: https://github.com/boot-clj/boot/blob/master/doc/boot.task.built-in.md#watch
I found some old stackoverflow answer stateing that this is not possible yet. Need to look what's under the hood, because file watcher like Hawk which figwheel uses, has :filter
key which should be easy to incorporate.
I’m running boot
containerized (from the official Clojure Docker image):
https://hub.docker.com/_/clojure/
Run this way, there is no tty.
lein
has a :headless
option to run w/o a tty. But I don’t see a corresponding one for boot
.
boot repl --server --port 8087
(as the container entrypoint) exits immediately with code 0
boot repl --port 8087
seems to try to enter an interactive nREPL and then:
backend_1 | boot.user=> Bye for now!
licenseapp_backend_1 exited with code 0
Outside the container (on my Mac) boot repl --server --port 8087
exits immediately too. I feel like if I could get that working (not exiting) I’d have a solution.
^ that doc comment seems out of date since it doesn’t match what I get from boot repl -h
genius! that causes the nREPL to wait (not exit). Progress!
works perfectly on the host: client can connect via boot repl --client --port 8087
and via Cursive from IntelliJ
running boot repl --server --port 8087 wait
in the container causes the nREPL to wait ✓ but I’m unable to connect any clients running outside the container. Even telnet connections are rejected.
Yes I’ve exposed port 8087 from the container to the host.
Bill:backend bill$ boot repl --client --port 8087
SocketException The transport's socket appears to have lost its connection to the nREPL server
clojure.tools.nrepl.transport/bencode/fn--2017/fn--2018 (transport.clj:95)
...
Bye for now!
adding: --bind 0.0.0.0
solved it. Here’s my entrypoint in my docker-compose.yml
now:
boot repl --server --bind 0.0.0.0 --port=8087 wait
[seancorfield/boot-tools-deps "0.1.2"]
-- https://github.com/seancorfield/boot-tools-deps -- a Boot task to read deps.edn
files using tools.deps.alpha
so you can specify your dependencies externally and use both the clj
script and Boot with them. This update exposes the logic from the deps
task as a function as well load-deps
so you can use it programmatically from other Boot tasks, as well as from the command line as an actual task.
That’s very cool for compatibility @seancorfield
I wonder why people would use deps.edn if you’re already using boot or lein right now, isn’t completely obvious to me
We use (a different format) deps.edn
so our dependencies are all external to our build file -- because we have one build file in {repo}/build
and all our separate subprojects in {repo}/clojure/{project}
-- and have deps.edn
for each {project}
.
We also do something like that, I wrote a library for that: https://github.com/borkdude/boot-bundle
We also, currently, use version.properties
as a top-level file (in {repo}/clojure
) to pin all our shared library versions. This is like :override-deps
in tools.deps
.
I'd like us to move to tools.deps
format deps.edn
files at some point, to "standardize" things. So having something in our build.boot
file that can read that new format instead of our custom one will be very convenient.
Being able to use clj
for quick command line work is appealing -- Boot drags in a lot of machinery, just to run a quick script, or open a REPL to try something out. I don't know how much we'd use that, but it seems like a useful option to have.
Besides, if folks standardize on tools.deps
for projects, then we can all use clj
, or lein
, or boot
...
(and, besides, it's fun to experiment with new libraries!)
It’s very cool to treat dependency data like actual data and program with it using boot
I can’t image doing something like https://github.com/borkdude/boot-bundle with lein
There is a Leiningen plugin already that reads deps.edn
but it only extracts :deps
right now and it doesn't handle the cascade of files or the aliases / overrides etc.
Also this was possible due to boot and ‘data’: https://github.com/borkdude/dependency-problem
Well, it just slurp
s and parses the file. It doesn't use tools.deps
. Leiningen is definitely harder to extend than Boot.
Yeah, understood 🙂 That dependency checker is nice -- it's interesting to see how folks are using spec now. We have an HtmlUnit test at work that uses spec to describe possible valid paths through one of our applications and then we use test.check
to verify a series of properties about the application when exercised in any combination of valid ways.
Takes a while, but it's very powerful to get so much test coverage so easily.