Fork me on GitHub

@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:

|- versions (the common deps folder)
|- project-a
|- project-b
|- ...
and then we cd into a project to work and run clojure like this:
$ CLJ_CONFIG=../versions clojure -A:some:aliases and args
and it uses versions/deps.edn instead of a user-level deps.edn file plus the deps.edn from the project-x folder that we are running in.


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.


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.


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


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


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