As a follow up, was deps.edn always envisioned to be open keys to outside tooling? Is it part of the philosophy that other tooling could use it to add more key/values to it for their own use?

top-level, no

but we thought it might have have procurer config extensions there. I regret putting the :mvn/local-repo and :mvn/repos there though. they may ultimately move under a :procurers key or something.

I think my line of thinking is, for example, with lein, the config file was called project.clj, with deps its called deps.clj. The names themselves reflect a bit of a different mindset. project.clj made it sound like this was the config for your project. deps.edn makes it sound like it's the config only for your deps. So a question that arise is for example, where do you store your project name, version, description, license, and url. In the official examples, they're stored inside build.clj as top level vars. As more user friendly, all-in-one, higher level tooling is built and meant to be used on top of tools.deps and build.tools. That tooling might need some config. Would it be in the spirit of tools.deps to put it all under an alias inside deps.edn, say have a :project alias with it? Or its more expected that another config file is made like project.edn ?

> So a question that arise is for example, where do you store your project name, version, description, license, and url. In the official examples, they're stored inside build.clj as top level vars. This is only one option of course - you can load these from an .edn file, load them from aliases in your deps.edn, whatever.

that is, tools.deps and tools.build do not answer this question. in general, if you want to make data accessible to both people and programs, .edn files are a good choice (or other formats more accessible to other toolchains if needed)

if you do put it in an alias in your deps.edn, one benefit is that it is also accessible in the basis you create in your build.clj

Ok make sense. And if say you were to build extensions on top of tools.deps. Say I need to start an alias and inject deps into a particular alias. Cider does this for example to inject its middleware. But for some reason, as part of that injection process, there might be some config needed, would it make sense to allow for new keys under the alias, maybe :cider/completion-engine ... for example. So when cider launches the alias it would inspect the alias for its own config as to what to inject into it before launching it.

"inject deps into a particular alias" - I don't know what that means

aliases are names for data. aliases provided on the command line via -A etc are data understood by tools.deps and the Clojure CLI itself.

I mean say you want to launch a repl under the user :dev alias. But you want it to have nRepl and the cider middleware for nRepl. You tell cider to run clojure -M:dev basically. It'll probably add extra-deps as it runs the command. But what if the extra-deps it adds are configurable, could it make it that the config is directly read from the :dev alias?

if you need to add stuff you can always add an additional alias - merging that data is handled for you by the CLI

and that can be provided ad-hoc via -Sdeps (or in basis calls via :extra)

Right, but the config is per-alias. So as a separate alias you'd need a reference back to each alias.

is this config that the CLI understands or just other stuff?

For example, Cider will run:

clojure -Sdeps '{:deps {nrepl/nrepl {:mvn/version "0.9.0"} cider/cider-nrepl {:mvn/version "0.28.3"} refactor-nrepl/refactor-nrepl {:mvn/version "3.5.2"}} :aliases {:cider/nrepl {:main-opts ["-m" "nrepl.cmdline" "--middleware" "[cider.nrepl/cider-middleware]"]}}}' -M:dev:cider/nrepl

{:aliases {:dev {:cider/completion-engine :foo, ...}}}

> is this config that the CLI understands or just other stuff? Other stuff. It would be for tools that make use of the cli or tools.deps.

why do you need to put it under :dev?

{:aliases {:my-cool-config {:dev {:cider/completion-engine :foo ...}}}}

your code can use the :dev alias as a lookup key in your own config

(I'm not convinced that this is actually per-alias data)

You don't per-say. Was asking like what you saw as best-practice for this stuff going forward. Personally I think config like that is more brittle, because like say I decide to rename my alias to :devo, its more remembering from my part that there might be other aliases that refer to this alias I also need to update, but it does work.

I think it's brittle to manipulate data controlled by other people :)

Isn't that kind of the point of namespaced keys though? The key is for some other namespace.

the more it can be additive, the less brittle it is

I agree. I just always thought that's what's beautiful about open maps and namespaced keys. You can allow them to be extended externally by people who don't control it.

I'm fine with that happening in the config file (and the code is written to be tolerant of that as much as possible). I'm objecting to the idea of "injecting", but maybe I'm just reading too much into that

I think I got the gist of the mental model: 1. deps.edn can be used for project/tool-level config, but that's just one option for how this could be done 2. If using deps.edn for project/tool-level config, prefer having a dedicated alias for them 3. If a dedicated alias isn't ideal for "good reasons", use namespaced keys 4. Don't add keys (even namespaced) to the top-level map

Sounds right