Fork me on GitHub

wouldn't it be good to have more deps.edn sources to load from ? (to recap now it's root/user/project/config(cli))


I am still thinking about the monorepo problem


it would be the missing piece to avoid having either to hijack the user level conf or do deps.edn generation, or pass something to the cli as string I think


I suspect i am not the first one asking that question


basically an option (or env var) to specify a comma separated list of deps.edn files at project level could be it. But maybe there are better ideas out there


🙂 indeed


I would make it "N files" so that people don't ask for the "fifth file" right after it's patched 🙂


yeah. in clj-kondo I support something like :config-paths ["foo" ...] so it will merge in foo/clj-kondo.edn and hooks, which in turn can include :config-paths relative to itself. You can set up an entire chain of configs. Basically a classpath of configs.


yeah that's a good way to solve the issue for good

Alex Miller (Clojure team)13:02:49

I’m not yet convinced that this is the answer. I also think it’s important to separate the problems of shared deps mgmt from shared tooling config

Alex Miller (Clojure team)13:02:25

I do not think N configs is a good answer

Alex Miller (Clojure team)13:02:36

And I think it’s pretty crummy to need to pass stuff explicitly


do you already have ideas for potential alternatives?


I mean, solutions to that problem

Alex Miller (Clojure team)13:02:18

I haven’t really sat down to think about it yet


Maybe something like juxt/aero #include tag could help compose a deps file from multiple sources otherwise. But that's static (no merging), even tho another tag could do that.


But that feels a bit odd now that I wrote it down


Is there an “official” way to run clj with a java that isn’t on the path?


JAVA_HOME="path to java home" clj …

👍 3

actually it should be JAVA_CMD="path to java executable" clj …

Alex Miller (Clojure team)15:02:47

no, the latter won't work


but only if java executable is not present in PATH, isn’t it?

Alex Miller (Clojure team)15:02:05

but that was the precondition in the original question


right, sorry, misread the original question


@alexmiller (or anybody else for that matter) a follow up question on my maven resolution question. It seems to me after reading up on this that maven poms can define extra repositories under the repositories element and that, if specified, the maven behavior is to use those repositories to resolve the dependencies for that pom instead of the one used to resolve the pom. Two questions really: a) I failed to find a definitive answer. This seems to be the maven behavior, but it does not seem to be well documented. Is there even a spec for this or is the implementation of maven the spec? b) does deps alpha use this mechanic of changing the resolution repository?


As a side note, it's interesting how maven discussions about resolution strategy (such as this one: ) do not distinguish between the resolution language aka poms and the structure and the implementation of maven itself. These days we have quite a number of different resolution engines (IDEs, gradle, tools, lein, sbt, ivy, etc) which need to use the resolution language and do not necessarily care about the implementation of maven. I.e. the above issue discussion only talk about command line switches etc when the issue really is that the resolution language has a feature that everybody needs to adhere to.

Alex Miller (Clojure team)18:02:04

there are lots of poorly considered impl magic in this area of maven (particularly around security)

Alex Miller (Clojure team)18:02:22

clojure/tools.deps will use the repos from the top-level deps.edn, and only those

Alex Miller (Clojure team)18:02:47

well, top level merge, which includes root/user/project deps.edn (central/clojars included in root)

Alex Miller (Clojure team)18:02:00

re security - I've more and more come to believe that allowing transitive deps to add (or worse, replace) repos to find things seems evil

😱 3

Agreed, seems evil. Perhaps resolution should fail at that point with a message containing the new repo so the caller can either add it or not, but at least be informed


Thanks for the reality check and info


Also, I'm generally somewhat surprised as to the level of disinterest in for example version conflicts and resolution logic given that everybody, their mother and the kitchen sink is built using these tools and run into these problems. Everybody is driving around in steam cars and are generally not interested enough to stop and wonder if there is a better way. I realize I'm preaching to the choir here, but still, surprising.

Alex Miller (Clojure team)20:02:00

it's really shocking that it mostly works at all :)


Is there a repo with the clj command line tools in (the scripts rather than the clj lib)? I just started work at a new place, and broke the build by upgrading to the latest version. They had a hacked/patched version that worked with http proxies. I think they might have opened a ticket, but I'm not sure which repo it would be on.


ah ok, and the linux install is in there too


ah there's no where to add an issue 😞


that would be the first place I could think of

Alex Miller (Clojure team)18:02:36

note that the scripts there have various string replacements that happen before the final version so you can't just use those directly

Alex Miller (Clojure team)18:02:12 is a repository for brew of old versions, but you can find the urls for tar/gz for old versions in those if really needed

Alex Miller (Clojure team)18:02:03

proxies are supported for mvn repos in the current version (but not for git deps), so maybe be more specific on what you need?


They'd patched it as described in one of the answers, so I've done the same for now.

Alex Miller (Clojure team)18:02:05

gotcha, def plan to fix that, but depends on larger direction with tools.gitlibs

Alex Miller (Clojure team)18:02:17

(jgit vs shelling out to git)