Fork me on GitHub

Is there a way to have an alias that uses the :extra-deps from one or more other aliases?


Or is the an obvious better way to organize this:

{:deps {
        org.lwjgl/lwjgl        {:mvn/version "3.2.3"}
        org.lwjgl/lwjgl-glfw   {:mvn/version "3.2.3"}
        org.lwjgl/lwjgl-opengl {:mvn/version "3.2.3"}

 :mvn/repos {"space-maven"
             {:url ""}}
  ;; copy of windows
   {org.jetbrains.skija/skija-windows      {:mvn/version "0.89.8"}
    org.lwjgl/lwjgl$natives-windows        {:mvn/version "3.2.3"}
    org.lwjgl/lwjgl-glfw$natives-windows   {:mvn/version "3.2.3"}
    org.lwjgl/lwjgl-opengl$natives-windows {:mvn/version "3.2.3"}}}

   {org.jetbrains.skija/skija-windows      {:mvn/version "0.89.8"}
    org.lwjgl/lwjgl$natives-windows        {:mvn/version "3.2.3"}
    org.lwjgl/lwjgl-glfw$natives-windows   {:mvn/version "3.2.3"}
    org.lwjgl/lwjgl-opengl$natives-windows {:mvn/version "3.2.3"}}}
   {org.jetbrains.skija/skija-macos-x64  {:mvn/version "0.89.8"}
    org.lwjgl/lwjgl$natives-macos        {:mvn/version "3.2.3"}
    org.lwjgl/lwjgl-glfw$natives-macos   {:mvn/version "3.2.3"}
    org.lwjgl/lwjgl-opengl$natives-macos {:mvn/version "3.2.3"}}}
   {org.jetbrains.skija/skija-macos-arm64 {:mvn/version "0.89.8"}
    org.lwjgl/lwjgl$natives-macos         {:mvn/version "3.2.3"}
    org.lwjgl/lwjgl-glfw$natives-macos    {:mvn/version "3.2.3"}
    org.lwjgl/lwjgl-opengl$natives-macos  {:mvn/version "3.2.3"}}}
   {org.jetbrains.skija/skija-linux      {:mvn/version "0.89.8"}
    org.lwjgl/lwjgl$natives-linux        {:mvn/version "3.2.3"}
    org.lwjgl/lwjgl-glfw$natives-linux   {:mvn/version "3.2.3"}
    org.lwjgl/lwjgl-opengl$natives-linux {:mvn/version "3.2.3"}}}}}

Alex Miller (Clojure team)15:02:46

in short, no. you can of course supply multiple aliases at the CLI, so the common stuff could be in its own alias

👍 4
Alex Miller (Clojure team)15:02:58

(also note you have a typo in extar-deps near the end)


good catch thanks!


makes me wonder: was it ever considered to add tagged litterals like in aero for referencing values (#ref) or even including deps.edn fragments from other files?


not sure it's a good idea, it just came to mind, merely curious

Alex Miller (Clojure team)15:02:45

I would not rule out ever having an answer to this question

😆 9
Alex Miller (Clojure team)15:02:02

(as an aside #ref is a bad tagged literal as it's not qualified and those are reserved for Clojure)

Alex Miller (Clojure team)15:02:28

(and "#ref" is particularly likely to actually potentially be a thing Clojure might want to use)


you should go into politics 🙂


agree about the naming


#include + #merge could maybe even solve the monorepo thing


or some derivative/form of #merge

Alex Miller (Clojure team)15:02:51

it's definitely a possible solution


I remember a conversation where this kind of feature was objected to since the EDN would need an external tool to be processed which makes it harder for tooling to reason about it.


you can always use a :default reader — you’ll probably need tools.deps the library to reason about the file anyway no?


i imagine tools.deps would give the means to have the final deps.edn form


Git coordinates would be safe, as well as Maven central dependencies (Since maven requires DNS validation to register a group). However, clojars does not have this validation


You’d need to know the effective GroupID, ArtifactID, and version of a package to execute it, and it’d depend on resolution order. IMO, you ought to register your org’s group on clojars just to be safe


Right. I guess you could build this into tooling as well, right, either by specify a repo hierarchy, or specifying which repo you’d want to fetch stuff from?


Yeah, if I have an artifact I know that should only ever be pulled from S3 or my .m2 for example, I’d need to specify that after the :mvn/version or, for certain dependencies just tag them with the :mvn/repos key?


Something like that


Actually, debugging access to remote deps would be a lot easier then too. I always have to stop and think whenever tools.deps reports it can’t find a private dependency on central

Alex Miller (Clojure team)15:02:07

tda/clj only uses the :mvn/repos at the top level, not in transitive deps.edn files, so you are in full control of which repos you look at

Alex Miller (Clojure team)15:02:28

also, we guarantee that the first repos searched are central, then clojars

Alex Miller (Clojure team)15:02:39

btw, maven central does not require dns validation, although there is a process with a human in the loop for verification of groupIds


What happens if I publish clojure to clojars under version 1.12 and someone depends on latest Clojure

Alex Miller (Clojure team)15:02:36

well first you shouldn't depend on "latest" clojure

Alex Miller (Clojure team)15:02:24

but would depend on what clojars allows there

Alex Miller (Clojure team)15:02:50

so good question for them

Alex Miller (Clojure team)15:02:01

maybe worth an issue for them, should really not allow uploads to org.clojure group there


> we guarantee that the first repos searched are central, then clojars Is this a desirable behavior when I want to pull in internal libs from an internal repo? Also, would it ever be an option to lock a specific dep down to be retrieved from a specific set of repositories? Say, I don't even want to allow clj to try central/clojars for my internal lib dep

👍 8
Alex Miller (Clojure team)13:02:33

We’re going through the Maven apis for that stuff and that’s just not how it works

Alex Miller (Clojure team)13:02:00

So would be a large and unknown amount of work

Alex Miller (Clojure team)13:02:33

The way most people handle this stuff at enterprise level is to use something like Nexus or Artifactory as a proxy in front of the internet

Alex Miller (Clojure team)13:02:06

tools.deps supports that via the mirror/proxy settings in settings.xml


I'm reading back the logs from this channel on the zulip archive. I'm at Feb 2019 now (2 years ago) where Sean Corfield talks about his monorepo problem. LOL I didn't realize we've been talking about that for so long already (


I now found the relevant part that I was looking for on 6th September 2020:

borkdude: @alexmiller I know tools.deps isn't going to expand ~, but I'd like to know the reason for this. Reason I'm asking is that I'm considering doing this in .clj-kondo/config.edn and would like to know if I'm missing some problems
Slack: alexmiller: Because then everyone reading deps,edn has to interpret the file
Slack: alexmiller: It’s no longer just edn/read, it’s that plus run magic code
Slack: borkdude: Why does it have to be interpreted by anything else than tools.deps which already does interpretation of this entire model?
Slack: borkdude: I mean, merge, assoc, etc still works for other tools in this case?
Slack: alexmiller: If you have alias data, anyone may be reading it via the basis (without tools.deps, which has a lot of deps)
Slack: alexmiller: There are a bunch of tools already reading and manipulating deps.edn. The less they have to know, the better
( I think the contextual beginning question is missing maybe due to some logging error.


oh yes, I think I remember what this was about: interpretation of env vars like HOME probably


For completeness, I now also found the other message via the other archive at clojurians logs:

borkdude: @alexmiller I know tools.deps isn't going to expand ~, but I'd like to know the reason for this. Reason I'm asking is that I'm considering doing this in .clj-kondo/config.edn and would like to know if I'm missing some problems


(I haven't implemented this in clj-kondo either, solved it a different way)


So the point was: the EDN should be readable by other tools without magic code / deps. I wonder if the opinion shifted on that (everyone is allowed to change their mind).

Alex Miller (Clojure team)16:02:15

it was never an absolute statement. my general preference is - the less you need to know/do to read, the better

Alex Miller (Clojure team)16:02:52

as always, it's a matter of tradeoffs

👍 3