Fork me on GitHub

[seancorfield/boot-tools-deps "0.1.1"] -- -- 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?


That would actually make the -c option redundant in my opinion.


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!


Just curious though, wouldn't you just want to do boot repl?


If your dependencies are in deps.edn, that won't work. That's the whole point of this.


I'm picturing a build.boot with a call to load-deps at the top?


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!


When you're running without a build.boot, is that mostly/entirely the repl?


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.


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


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): 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?


herm this is apparently the original repo, abandoned in 2014 or so


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 (transport.clj:95)
Bye for now!


adding: --bind solved it. Here’s my entrypoint in my docker-compose.yml now:

boot repl --server --bind --port=8087 wait


[seancorfield/boot-tools-deps "0.1.2"] -- -- 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:


We also, currently, use 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.


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


(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 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’:


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.