Clojurians Log v2

@colliderwriter What we have done at work is to take advantage of the (undocumented?) CLJ_CONFIG environment variable to point the "user deps" path at a directory in our monorepo and have all the common aliases, overrides, etc in a deps.edn file in there -- including aliases for all the tooling needed for working across all the projects in our monorepo.

So our repo structure is:

clojure
|- versions (the common deps folder)
|- project-a
|- project-b
|- ...

$ CLJ_CONFIG=../versions clojure -A:some:aliases and args

thanks for that. it will get the gears to mesh so i can move on today, but i foresee a problem with devops once i try to hook that up because bazel/rules_clojure won't know how to do that. This seems like a missing feature in tools.deps, especially because this is possible via lein-parent in old money. I guess i should go look at the I wish there were an issue list to see if anyone else has asked for this.

@colliderwriter You mean this https://clojure.atlassian.net/projects/TDEPS/issues ?

I sure do. Thanks again.

Given that it is driven via an environment variable, and that could be automated via a simple "build" shell script in the repo, I don't see why it would cause problems for devops.

It has the benefit that you can control all tools directly within the repo since that "main" deps.edn file is under version control with everything else.

I absolutely agree that the shared files are in the right place. I'm already using Bazel to do my builds and it is pretty opinionated. I'll have to look into my options there.

in case anyone's curious https://github.com/simuons/rules_clojure

Wow, that looks horribly restrictive. I'm sorry 😐

I don't know bazel, but I suspect slot of those 'srcs' instead of being lists of source files should be directories containing source files

clj, lein, boot, most clojure tooling has you specify what ends up being classpath roots (directories of classes or source code, and jar files via deps) not individual source files

It is kind of a shame to have to explicitly list intra mono repo dependencies, given a closed mono repo world you can derive a project dependency graph from the namespace dependency graph