> > I’m curious as to how you define this tool: what exactly do you consider a > “dependency manager” to be, and what are it’s specific functions/features? > You talk about having an “internal dependency manager” – how do you > leverage that from Clojure? >
By dependency manager, I mean a system that defines "packages" and dependencies (including transitive) between them. Which can also retrieve those packages, and generate the dependency graph. I'll try to explain, but my work highly values reproducible builds. And so everything stems from that. Think of reproducible build as the idea that you can regenerate the identical artifact and environment produced by a past deployment. So our packages are managed by some system, each package is just a git repo with some config file that defines the dependencies of the package on others. This is what I call the "dependency manager". It tracks package dependencies, where in our case, packages are git repos. You can ask it to generate the dependency graph of a given package, and you can also use it to retrieve all packages into a local copy, and generate a classpath pointing in the correct order to all the local copies. At this point, it is a lot like tools.deps. Except that it also has a global registry with additional meta data support for packages, like versions. Another difference is that it is tied into our build and deployment process. When you build a package, the build system uses the dependency manager to pull down all transitive packages of the defined version, it then proceeds to build them in order. All artifacts are then cached in an artifact repository. The package thus references a git repo, each package version maps to an exact commit, and artifact build cache. When we deploy, it's just the same thing that happens. The host uses the dependency manager to build the dependency tree, but the difference here, is that, instead of retrieving the git source for the specified commits of the specified versions of each package, it will grab there corresponding cached artifacts as a performance optimization. So now, when it comes to Clojure, I can't use lein or tools.deps to retrieve package dependencies, since they don't know about our internal packages and how to retrieve them. I already have a configuration format to specify dependencies on other packages, and a cli tool which can retrieve them locally (either their source or their corresponding built artifact) from our internal source and artifact repos, and can also generate the classpath. What I don't have though, is a way to perform Clojure build tasks, like run tests, generate coverage reports, perform AOT, generate Java classes, etc. I can't use lein for that, since I couldn't find how to have it use a custom classpath for all of its tasks, it seems to always implicitly assumes it will retrieve the packages itself and build the classpath. So I basically use Ant. Which surprisingly, is one of the last build tool that does not complect itself with dependency management as well. So I can use it purely to build. And I created custom Ant tasks for the Clojure related tasks I needed. I'd love a standard Clojure build tool that is decoupled from a dependency manager, which I could use instead of Ant, and where I didn't have to write the Clojure tasks myself. Though since I do a lot of mixed Java/Clojure project, it would need to also support Java build tasks. So who knows, I might never have the full package I dream off. Something else that is really painful is bringing in an external Clojure package internally. I'm forced to re-write the dependency format to our internal one. So if it's project.clj or deps.edn, I need to change it to our internal one. Also painful is having to retrieve the source for these, and make an internal source copy. I feel like tools.deps might actually help me here long term, if everything move to source only dependencies, I could leverage it to transitively retrieve and copy over all source and their source dependencies. Sorry for the long wall of text, but this stuff is actually kind of complicated. On Sunday, 4 November 2018 15:35:29 UTC-8, Sean Corfield wrote: > I guess I see the need for a dependency manager. > > > > I’m curious as to how you define this tool: what exactly do you consider a > “dependency manager” to be, and what are it’s specific functions/features? > You talk about having an “internal dependency manager” – how do you > leverage that from Clojure? > > > > Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > > ------------------------------ > *From:* clo...@googlegroups.com <javascript:> <clo...@googlegroups.com > <javascript:>> on behalf of Didier <did...@gmail.com <javascript:>> > *Sent:* Sunday, November 4, 2018 10:58:43 AM > *To:* Clojure > *Subject:* RE: What's the end goal for tools.deps? > > 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. > > That said, I do prefer the tools.deps abstraction. Just feels a little > like reinventing the wheel. > > 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. > > Regards > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clo...@googlegroups.com <javascript:> > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+u...@googlegroups.com <javascript:> > 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+u...@googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/d/optout. > -- 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.
