> > Generally those tools are just Clojure programs with a clojure.main. If > you can build a classpath from your dependency manager, then invoke the > tool, then yes, all those tools are open to you as well (and for packaging > as lein plugins or boot tasks too). There is no magic here. It's just > running Clojure programs. >
Currently, we perform all build tasks using custom Clojure code. We have our own test runner, and script to launch cloverage, kibit and eastwood, we AOT compile and package a hybrid JAR of source and .class (to support consumption from Java and Clojure). But I've always wanted to leverage existing work for these, as it can get complicated. I never figured out in Lein how to swap the dependency resolution logic with our own, and just leverage the build features and the accompanying plugins. There's no way to just provide the dependency tree or the classpath to Lein that I could find. It seems tools designed for tools.deps might be easier for me to leverage, like https://github.com/cognitect-labs/test-runner. This looks pretty great, I'll see if I can swap to it instead of out custom test-runner. > I know Rich hopes strongly that the Clojure community is a place where > people are free and supported when attempting to creatively solve problems > in new ways. Certainly Clojure itself wouldn't exist if the community > wasn't willing to try something new and different. Sometimes you have to > start over, with a new set of assumptions and constraints and see where it > goes. > Definitely, though I do hope we won't be experimenting with dependencies much more. It's hard to keep up, maven, lein, boot, now clj, throw in ClojureScript and you need to deal with npm too. It gets quite complicated. To me, this is mostly accidental complexity created by the lack of a common standard. At least tools.deps has enough of a differentiator, I can recognize its worth the change. Being official is really key to me, so I'm happy. The risk I see is that you can end up in a place where dependency resolution becomes incompatible. Say you depend on package X, and it uses a different dependency declaration format. Now you can't resolve its dependencies. This can also happen for build logic. Though it's not as bad a problem in Clojure. There's packages that say need to pull in resources, or must perform AOT, and if you depend on such a package source, you can't transitively build it if the build process declaration is in incompatible formats. Anyways, I was mostly curious, just wanted to understand better the rationale. I'll look forward to what happens next, and I assume things will standardize around it more and more, which will solve most of my issues. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
