As people discovered on various occasions Boot may download dependencies at any point in time to create isolated Clojure runtimes (“pods”). These are super useful to prevent dependency conflicts introduced by tooling helping you to avoid dependency hell as long as possible.
Not knowing what dependencies will be needed for various tasks can be a bit annoying though. In Continous Integration (CI) you usually want to download your dependencies once and cache them. Without knowing all dependencies up front that’s impossible to do. (The current workaround is to just run your tests during the setup stage but that’s not nice really.)
The deps.edn format that’s part of tools.deps.alpha sparked an idea that might fix this: tasks could expose their dependencies via deps.edn files.
When packaging jars containing boot tasks which may use pods, include a file ending in .pod.deps.edn specifying all required dependencies
During the setup stage of your CI process, scan the classpath for these files and resolve/download all dependencies specified within
I’m a complete Boot novice, so I don’t understand all of the fine details here, but it seems like a good idea and would solve the problems I have. Leiningen plugins also have a similar issue, and this kind of approach could be applied there too.
Ultimately it would be great if this could become a standard and be built-in to Boot, but prototyping it outside seems like a good approach.
When I built boot-tools-deps one of things I felt was important to expose was the ability to leverage the aliases in deps.edn files to support overrides, defaults, and extras etc. Leveraging that tools.deps functionality consistently is something that I think all tools trying to build on deps.edn files should do.
Simply reading in a local deps.edn file and pulling the :deps out of it is misleading, in my opinion, and misses out on a lot of what makes tools.deps so powerful.
With some refactoring, boot-tools-deps could more easily support use within pods or even as a way to just display what the dependencies would be. It already has most of the logic in a function load-deps rather than locked into a task, so that it can form the basis of other Boot tooling. @martinklepsch opened an issue on GitHub to trigger that refactoring and a discussion about pods – feel free to post thoughts in there too.
As I told Martin, I’m a bit snowed at work through year end but happy to continue work on boot-tools-deps as and when I can.
I think I understand. And for a project’s deps.edn loader I totally agree.
Just pulling out :deps and ignoring the rest is a bit weird. That said I consider the usage of tools.deps more an implementation detail here. We might as well just use an edn file with a traditional dependency vector and some boot functions to download the deps (these would be in boot.aether I guess).
99% of the time when creating pods you just add some dependencies to a fresh or existing boot env.
Do you see any way in which deps.edn profiles could be useful for pods?
Then when creating pods, the task would specify the alias and tools.deps would load given deps. To download these deps beforehand, we could find all the deps.edn files in classpath, under META-INF/maven/groupId/package/deps.edn or something, and load deps for all aliases tagged with :boot/pod?.
Not sure though if the packages are going to include the deps.edn file, or if aliases can contain extra data.
And when downloading dependencies, we could find any pom.xml in classpath with this property, and then read the dependencies from some part of the pom.xml. Maybe some scoped dependencies (like test), or maybe dependencies of from some specific Maven profiles. Boot pom task probably can’t currently write such pom.xml but that shouldn’t be to hard to extend.
One of the things I use pods for is to run tests with different versions of Clojure (or different versions of some other dependency) so, yes, being able to use the aliases to indicate which set of dependencies to use in the pod would be very valuable.
Putting it into a more standard location like META-INF is a good idea but introduces some additional complexities during development since you don’t have a jar at that point. (Same issue applies to putting it in pom.xml.)
I like the idea of having pod dependencies specified as aliases with a specific tag though.
I have mostly been thinking about pods inside boot-tasks which are opaque to the user of the task. What you describe seems like a situation where you create the pods yourself and thus are aware/in control what goes into them.
I do agree however that an API to make a pod from a deps.edn file (+ any parameters like profiles) would be very nice.
As Juho showed, the basic idea is to simply store the deps somewhere where it can be read afterwards. I personally would prefer edn over xml so the idea of using deps.edn appeals to me.
One of the things that I wanted to add to the list of requirements would be to dynamically modify the pod classpath. Maybe in phase two of this change, but many many times I have wondered if I could add a dependency to the pod while developing stuff (boot-figreload for instance).
Towards that goal if the we store each pod deps in an .edn in the jar, we should also think of a mechanisms to “override” those deps from a local file. But hey, we already have something like that in current tools.deps. If we represent pod deps as Juho wrote above, with aliases, then a “local” deps.edn could contain :override-deps for a certain pod key and voila’, your pod now reads it and loads the new dep.