On Sunday, November 4, 2018 at 12:58:43 PM UTC-6, Didier wrote: > > Thanks everyone. > > I guess I see the need for a dependency manager. And I love having a CLI > to launch Clojure programs. And I understand it is fundamental. That said, > it always felt like Lein had solved that problem long ago. Maybe it wasn't > official enough. But Lein could have been bundled with Clojure and > effectively solved the same problems and more. >
Lein is an excellent "better Maven" for Clojure and it has served an incredibly important role in standardizing project structures and making it easier for Clojure projects to consume and deploy Maven artifacts, particularly to access the vast Java ecosystem to the Clojure community. However, we believe there is a better path that starts from reconsidering the problem space without using a Maven-artifact based dependency system, and instead thinking about what Clojure projects need. While consuming Maven artifacts is important, an artifact-centric world is more limited than it needs to be in Clojure. Clojure fundamentally works from source on the classpath. Note the lack of the words artifact, compile, or build in that statement. Taking this approach is what allows us to easily consume some Clojure source that happens to be sitting on github in a repo. Or a db driver sitting in a jar on the disk. The producer does not need to build and deploy an artifact into Maven. The consumer does not need to download an artifact. We can simply consume the source directly without these middle systems. > That said, I do prefer the tools.deps abstraction. Just feels a little > like reinventing the wheel. > 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. > I'll be interested to read your blog posts Sean. > > At my work, I can't use tools.deps, because we have an internal dependency > manager. And all dependencies are imported and vetted in it first. So I've > always wanted a build tool that was decoupled from dependency management. > Since tools.deps only outputs a classpath, I assume all these extra tools > you mentioned using to build and run your tests and deploy somehow work > only given a classpath. They might be useful to me. > 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. -- 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.
