Fork me on GitHub

what's the uberjar alternative "du jour" ?


something rock solid


I mean a clj plugin that would replace lein uberjar


I use seancorfield/depstar in my deps.edn


:uberjar {:replace-deps {seancorfield/depstar {:mvn/version "2.0.165"}}
                     :jvm-opts [""]
                     :exec-fn hf.depstar/uberjar
                     :exec-args {:jar foo.jar
                                 :group-id bar
                                 :artifact-id foo
                                 :version "0.0.0"
                                 :aot true
                                 :sync-pom true}}}


@dharrigan ah right. they also uses that extensively I think, so it's a good bet I guess


oh it's supports aot even


for deps.edn depstar is my thing now too


And there's a #depstar channel for questions/problems. I'm working on a new release today (that will remove the pom.xml requirement for folks who want to ignore/omit that, amongst other things).

👍 1

I know theres a way to add dependencies with add-lib3 branch of tools.deps.alpha. but is there a way to change a dependency in a running repl? e.g. change a dependency from being a Maven provider to a local provider and then reload the namespacees so you can use the local code instead? might not even be possible on the jvm but I don't know for sure. Thanks!


@kevin.krausse Assuming it is Clojure source code, you could probably do it manually by editing up the various source files in that local repo and evaluating them into your REPL (but you can't do it via dependency management AFAIK).


not possible


Sounds like a hack to me that's more trouble than its worth :)


What Seancorfield describes is something I've been doing regularly pre deps.edn, when e.g. debugging libs from clojars. Just copy paste the file from the jar and REPL on.


awesome, thanks a lot!


Is there a way to include an external deps file from, say, a git submodule in a project's deps file? I'm trying to give other devs access to clojure-deps-edn without either 1. making them modify their dot clojure since this is project-level from their perspective 2. hand-editing the project's deps I can add 'clojure-deps-edn' as a git submodule but how best to wire it at the project level?


@jasonhlogic if you use the git submodule as a local/root dep, the top-level deps.edn will also pull in the deps of the submodule deps, right?


I think we have a pending jira about submodules


in that they don't work


deps.edn {local/root: submodule}
submodule/deps.edn {cheshire, transit, paths: [src]}
now deps.edn will also include cheshire, transit and the submodule src path?


@borkdude I have an additional complicating factor: This is a fullstack app so the top-level has no project. There are several subprojects under /projects with their own deps files. I'm certainly willing to edit each deps file, but if I can only depend on filesystem hierarchy to get to submodules then i'm still out of luck


@jasonhlogic Your goal is to include a set of libraries in each of the submodules? Or something else?


is this polylith?


if so, I think you should file an issue with them as I've been having similar discussions about this structure


Ah, that might explain why @tengstrand (I think) reached out to me via DM with questions about our monorepo setup with deps...


@borkdude My goal is to provide access to practicalli/clojure-deps-edn , which while technically including other libraries, is more like "additional tooling" than "additional libraries". I was hoping for something like an :include in deps files


The way I would solve this right now is very bluntly, like this: - make one template edn, like - write a script: - update deps.edn with tooling using script. There is no support in tools-deps for this right now afaik.


@borkdude Thanks, will do


Ah, that might explain why @tengstrand (I think) reached out to me via DM with questions about our monorepo setup with deps...


@jasonhlogic For a while, we were using the CLJ_CONFIG "hack" to select a "user" deps.edn file for combination with a subproject's deps.edn file in our monorepo. But that's problematic because then developers can't have their own tooling setup. So eventually we caved and went to a deps-generation approach. Each subproject has <subproject>-deps.edn and we have a small Clojure script that reads that and the "common" deps template and merges them and spits out deps.edn. We keep .md5 checksums of all the template files and we automatically regenerate them in our build script (which wraps clojure) if either the common or subproject template has changed.


Yes, it was me that reached out to you @seancorfield, and here is the issue ( including a discussion with Alex about the #polylith workspace structure.


Yeah, every time I've looked at Polylith it's just looked like overkill formalism -- and I think the rigidity you've adopted is part of what's causing you problems with deps.edn and tooling. I agree with Alex's comment that you're aiming at an "easy" solution instead of "simple" as well and that's also causing you headaches.


BTW @tengstrand I notice that your #polylith channel here does not have either @U055W814A or @UFNE73UF4 as members so none of that conversation is being logged anywhere, and therefore isn't searchable. You might want to add both of those bots to improve the discoverability of your discussions.


We agree that the #polylith way of structuring code is opinionated and we respect that you (@seancorfield) think it’s overkill formalism, but we don’t agree. Polylith may look alien to people, in the same way Clojure looks like a bunch of parenthesis, added for no apparent reason. But the parenthesis are there to solve fundamental problems, and the same is true for Polylith. It is no coincidence that a component lives in its own src directory, that it’s just “plain code”, that it has an interface, that it’s only allowed to depend on interfaces (and libraries) and that it lives in a monorepo. All those things are there to decouple our system(s) into small Lego-like bricks in a way that they can be shared and put together in a meaningful way. Components are very similar to functions in that way, but operate on a higher level. A function is composable, easy to reason about, has a well defined interface and is fundamentally simple. A component is also composable, easy to reason about, has a well defined interface and is fundamentally simple.  Teasing things apart so that they can be composed together is often a sign of good design. It has been as hard to convince people that Polylith is a good idea as it has been to convince them that Clojure is. Our experience though, is when they start using either of them, they will soon discover how simple they are, how fun they are to work with and how productive you get, and that’s why we love Clojure and Polylith.


Since we were already generating an "everything" deps.edn -- so we could easily start a REPL with all of our monorepo's code and all the dependencies for our dev work.


Basically, it's like Polylith without the rigid formalized module interfaces.


The CLJ_CONFIG hack doesn't work for his case, since he wants to include basically aliases from another deps.edn file


CLJ_CONFIG=path/to/that/deps clojure -M:aliases:from:that:deps:and:other:aliases works though.


yeah, it kind of does, I guess


But it excludes your own user deps.edn.


It's how we worked for a year or so.


I was thinking of the nil version in combination with CLJ_CONFIG, which is what we are using it for


We use {} for the version and :override-deps in the master deps file.


but I'm thinking of using a scripting + template approach instead, feels more robust


at least the deps.edn you see is the deps.edn you get


We had a :defaults alias in the common deps file. Well, we still do, but that's in the common deps template now 🙂


Yup, local deps getting updated still breaks stuff though -- but that's a known issue with the CLI/t.d.a already.


Having the ability to add an extra deps.edn file into clojure's invocation, between user and project, would solve this.


@alexmiller I gather folks are still asking for that "fourth file" in various guises?


I haven’t forgotten it :)


@seancorfield I can make that work. Thanks for the suggestion. Happily, we already use (non-clojure but useful) to package commands for devs and devops, so I can use that to add the environment hack you suggest.