This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-02-10
Channels
- # asami (2)
- # babashka (28)
- # beginners (91)
- # calva (38)
- # cider (7)
- # clj-kondo (20)
- # cljfx (3)
- # clojure (88)
- # clojure-austin (1)
- # clojure-australia (2)
- # clojure-bay-area (10)
- # clojure-europe (68)
- # clojure-france (8)
- # clojure-italy (14)
- # clojure-nl (4)
- # clojure-sanfrancisco (1)
- # clojure-uk (14)
- # clojurescript (37)
- # clojureverse-ops (14)
- # clojurewerkz (1)
- # clr (1)
- # conjure (13)
- # cursive (10)
- # datascript (30)
- # datomic (6)
- # emacs (13)
- # exercism (3)
- # fulcro (10)
- # graalvm (4)
- # graphql (2)
- # instaparse (5)
- # jobs (3)
- # kaocha (10)
- # off-topic (20)
- # pathom (17)
- # polylith (7)
- # re-frame (25)
- # remote-jobs (1)
- # shadow-cljs (60)
- # spacemacs (5)
- # specter (1)
- # startup-in-a-month (1)
- # tools-deps (48)
- # vim (4)
- # xtdb (11)
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 ""}}
: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?
(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)
Indeed see this issue: https://github.com/juxt/aero/issues/44
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?
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?
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
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
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
> 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
We’re going through the Maven apis for that stuff and that’s just not how it works
So would be a large and unknown amount of work
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
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 (https://clojurians.zulipchat.com/#narrow/stream/180378-slack-archive/topic/tools-deps/near/157547436).
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
(https://clojurians.zulipchat.com/#narrow/stream/180378-slack-archive/topic/tools-deps/near/209221777)
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
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