Fork me on GitHub

If I were to store some information about a project in deps.edn, what's the best place? A top level org-name fully qualified key or a similarly keyed alias?

Alex Miller (Clojure team)21:08:55

aliases are places to store arbitrary data under a name

👍 1

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?

Alex Miller (Clojure team)05:08:54

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 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 ?

Alex Miller (Clojure team)18:08:30

> 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.

Alex Miller (Clojure team)18:08:22

that is, tools.deps and 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)

Alex Miller (Clojure team)18:08:20

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.

Alex Miller (Clojure team)18:08:01

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

Alex Miller (Clojure team)18:08:55

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?

Alex Miller (Clojure team)18:08:43

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

Alex Miller (Clojure team)18:08:25

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.

Alex Miller (Clojure team)18:08:47

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
So it can inject an alias and deps form the command. But if say I wanted to tell Cider, for my dev alias, use an older version of the middleware, or use a specific completion engine for example. It be nice to do in my deps.edn:
{: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.

Alex Miller (Clojure team)18:08:46

why do you need to put it under :dev?

Alex Miller (Clojure team)18:08:09

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

Alex Miller (Clojure team)18:08:44

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

Alex Miller (Clojure team)18:08:54

(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.

Alex Miller (Clojure team)18:08:04

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.

Alex Miller (Clojure team)18:08:56

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.

Alex Miller (Clojure team)18:08:10

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

👍 1

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