has anyone been thinking about how the new tools.deps stuff could be integrated with boot? https://clojure.org/guides/deps_and_cli Specifically reading the cached classpath files to start a boot environment?

adamfrey no, but i just read that, but i can imagine a task that loads the file into core or into a pod for you

another extension point might be the set-env! multimethod... (set-env! :deps "deps.clj" ...)

I found this, which could be a starting point: https://github.com/micha/boot-cp

fyi, a lot of the details on the deps_and_cli page will be changing soon (general process still the same)

while we have talked about ways to build classpaths that leverage pom.xml/project.clj as project descriptors, it’s a lot harder to deal with boot as there is no standard data definition of deps. So, I think it will require integration from the boot side if there is a desire to make use of tools.deps and deps.edn style deps.

Alex, I was thinking that a boot task that would probably duplicate most of the logic in the clojure executable as it exists here: https://github.com/clojure/brew-install/blob/master/src/main/resources/clojure. So a project could have a deps.edn file and a build.boot file and if you wanted to run a boot task with a given classpath alias, my boot task would fetch the cached classpath or call clojure.tools.deps to create it

so there’s really two pieces there - the classpath construction, which is certainly a place where you can invoke tools.deps.alpha

and the other piece is the classpath caching, which is primarily in the domain of the script

I certainly am all for building on the former - it exists for that purpose

the latter should be considered implementation detail of the clojure script and I have plans to change how the caching is done (there are some known issues with it) so I would hesitate to recommend replicating that logic. That said, there is nothing preventing you from using any caching strategy you like.

ok, that's good to know

but from my perspective, it seems like boot and deps.edn files could exist in relative harmony like, tomorrow with some boot task. Whereas leiningen would need some support from either the Lein side or the clojure org side

@alexmiller @adamfrey is classpath caching at the moment what yarn does with yarn.lock ? So a file to store resolved deps? Having worked on pomegranade in boot a bit (PR pending), I see no obstacle in calling tools.deps from inside boot.

I don’t know anything about yarn

it’s simply computing and caching the classpath string to avoid recomputing it if the deps haven’t changed

is it that expensive to calculate the classpath?

At World Singles, we already keep all our dependencies in deps.edn files but they're a slightly different format (just dependencies) and we combine them across multiple subprojects as needed. We'll have to rename our files to avoid confusion -- or convert them to the new format if it makes sense. Having a "built-in" way for Boot to load and use these new deps.edn files seems like a good idea.

(we keep a version.properties file with the specific versions of all the dependencies we want and use that to modify the dependencies on the fly as we read our deps.edn files -- but I think the overrides/defaults mechanism in the new tooling would serve the same purpose)

yeah, you should be able to use default-deps for exactly that

m2 is a cache, the source of truth is the .pom associated with an artifact on the repo server. when you request an artifact with maven, its .pom is processed, and the .poms for the artifacts it lists get downloaded also and so on

can someone explain to me in simple words diff. between with-pass-thru & with-pre-wrap & with-post-wrap. pls

@ag - with-pass-thru allows you to inspect the fileset but passes it on as-received - with-pre-wrap allows you to modify the fileset before the next task is called - with-post-wrap allows you to modify the fileset after the next task (+ tasks that task is calling) is called

so, I need to hold on to the fileset's temp-dir, the temp-dir where it puts compiled .js files (I want to catch its path and direct test-runner - Karma to run against files in that dir)?

how should I do that?

@ag why do you want the temp dir instead of using target?

hmmm... right, a) I thought it would be faster to run it against files in the fileset directly b) I'm having strange wacky problem with Karma, it doesn't seem to be picking up changes (its watch doesn't work as expected)

target should be reasonably fast

re: b) are you intending to run karma from boot?

@martinklepsch hold on, I think I found the issue.. my karma.conf has wrong stuff

is there a way to set the cljs-test reporter from boot-cljs-test? I’m currently running my tests using orchestra and expound and would like to pprint the output. right now it’s quite scary as it prints the whole data structure with the nicely-formatted expound message as escaped string

does anyone have a working version of a workflow that integrates adzerk.boot-cljs with Karma server? I want a pipeline that: - runs cljs-build with a watch (that rebuilds whenever something changes in .cljs|.cljc|.clj - runs Karma server with a watch (that re-runs the tests whenever cljs-build emits new .js) - ideally it should be fast and immediately show if tests are breaking and I'm having troubles, for some reasons --single-run works fine, but having to keep Karma continuously to watch for changes doesn't seem to be working as expected. - first, I'm having to pipe cljs-build into target, and have karma.conf.js configured for that directory, I assume technically there's a way to run it against tmp dir in fileset (but that's an improvement and a gimmick) - second - as I said, it works correctly the first time, the consequential changes making Karma act very strange, it first reports that it executed 0 of n tests succesfully, then it would say it's disconnected, then it finally may or may not show the right message. Clearly it something to do with Karma and not boot. But I'm having trouble to configure things correctly. I've tried playing with all sorts of options in karma.conf - still doesn't work as I wanted

I'm using https://github.com/honzabrecka/karma-reporter

another problem is - I can't run karma server before it's done with building cljs, it throws an error, but also does not pick up changes later. I don't like that, I want to find a way to run it and not run tests until later