Sounds like you’re in dire need of an internal installation of artifactory.
Most build tools let you specify custom repositories, and you could then choose to _only_ use artifactory, both as a repo for the public packages you choose to use, and for your private packages. The you can use lein, boot, clj or whatever. Erik. -- i farta 5. nov. 2018 kl. 01:43 skrev Didier <didi...@gmail.com>: >> 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 <clo...@googlegroups.com> on behalf of Didier >> <did...@gmail.com> >> 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 >> 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 >> 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. >> 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. -- 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.
