[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!

With the builtin (watch) task, how do you specify files to ignore?

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.

Do I need to give the nREPL something to keep it busy so it doesn’t exit immediately?

ah I see: https://github.com/tailrecursion/boot.core/blob/87abc32c51e0c2652de0b50ccbdc6dca911be9e6/src/tailrecursion/boot/core/task.clj#L287

now if I can figure out how to invoke a subtask…

^ that doc comment seems out of date since it doesn’t match what I get from boot repl -h

Nor does it comport with the code in repl.clj apparently

@bill: does boot repl --server --port 8087 wait work?

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.

Right

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.

I tried clj vs lein vs boot but it doesn’t matter much, like 1 second maybe?

Besides, if folks standardize on tools.deps for projects, then we can all use clj, or lein, or boot...

Yup

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

That’s always a headache… like in OO 😛

Also this was possible due to boot and ‘data’: https://github.com/borkdude/dependency-problem

Well, it just slurps and parses the file. It doesn't use tools.deps. Leiningen is definitely harder to extend than Boot.

I mean overriding things

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.

Cool