This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (82)
- # bitcoin (1)
- # boot (38)
- # cider (6)
- # cljs-dev (13)
- # cljsrn (5)
- # clojure (320)
- # clojure-italy (22)
- # clojure-losangeles (6)
- # clojure-russia (55)
- # clojure-spec (25)
- # clojure-uk (48)
- # clojurescript (64)
- # component (16)
- # core-async (6)
- # cursive (54)
- # data-science (2)
- # datascript (2)
- # datomic (8)
- # docker (1)
- # ethereum (1)
- # fulcro (1)
- # garden (1)
- # graphql (16)
- # heroku (6)
- # hoplon (12)
- # jobs (4)
- # juxt (1)
- # leiningen (9)
- # off-topic (39)
- # om (13)
- # om-next (2)
- # onyx (9)
- # pedestal (2)
- # portkey (12)
- # re-frame (25)
- # reagent (6)
- # ring-swagger (4)
- # schema (1)
- # shadow-cljs (10)
- # spacemacs (11)
- # testing (19)
- # uncomplicate (1)
- # unrepl (6)
- # vim (21)
- # yada (3)
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" ...)
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.
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.
it’s simply computing and caching the classpath string to avoid recomputing it if the deps haven’t changed
it requires a) starting a JVM and b) potentially making many network calls to read artifact metadata and/or download artifacts. so, potentially yes.
ah, I was thinking from the perspective of boot or lein.
a is given.
b confuses me, is there additional metadata not kept in ~/.m2?
and if you are using any SNAPSHOT versions, they will be re-requested, I think on a daily basis by default
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)
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
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)?
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)
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