Clojurians Log v2

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 "<https://packages.jetbrains.team/maven/p/skija/maven>"}}
 
 :aliases
 {
  ;; copy of windows
  :dev 
  {:extra-deps
   {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"}}}

  :windows
  {:extra-deps
   {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"}}}
  :macos
  {:extra-deps
   {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"}}}
  :macos-m1
  {:extra-deps
   {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"}}}
  :linux
  {:extar-deps
   {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"}}}}}

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

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

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

good catch thanks!

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

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

(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

Indeed see this issue: https://github.com/juxt/aero/issues/44

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

or some derivative/form of #merge

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

Just saw this https://www.bleepingcomputer.com/news/security/researcher-hacks-over-35-tech-firms-in-novel-supply-chain-attack/ how does tools.deps work in this scenario?

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

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 (https://clojurians.zulipchat.com/#narrow/stream/180378-slack-archive/topic/tools-deps/near/157547436).

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

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

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

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

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

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

but would depend on what clojars allows there

so good question for them

seems like they do have some old releases there https://clojars.org/org.clojure/clojure

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

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

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

as always, it's a matter of tradeoffs