This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-09-27
Channels
- # announcements (1)
- # aws (8)
- # babashka (77)
- # babashka-sci-dev (8)
- # beginners (29)
- # biff (2)
- # calva (13)
- # cljs-dev (1)
- # clojure (42)
- # clojure-europe (205)
- # clojure-nl (1)
- # clojure-norway (5)
- # clojure-uk (4)
- # clojurescript (58)
- # conjure (9)
- # data-science (7)
- # datalevin (19)
- # datomic (3)
- # emacs (7)
- # fulcro (15)
- # gratitude (8)
- # lsp (52)
- # meander (3)
- # membrane (92)
- # off-topic (12)
- # re-frame (16)
- # reagent (4)
- # reitit (15)
- # releases (1)
- # sci (30)
- # shadow-cljs (34)
- # tools-deps (5)
- # xtdb (17)
Is there anything to be wary of when requiring the same gitlib twice in a project using different :deps/root
?
I think the big one is if there are transitive local deps via git deps (as they can’t be compared)
That could be mitigated by using the same SHA but essentially those transitive local deps would be imported twice, right?
Ah, I might have misunderstood your statement. Let me provide some context.
I'm looking for an efficient way of sharing libs in a nascent public monorepo. Exposing them as git deps with :deps/root
seems to be the most straightforward approach.
Let's say that:
A) Consumers must always use the same SHA when importing more than 1 lib
B) Those libs refer to other local libs via :local/root
Thinking more about it, my concern is that something might go wrong indeed with those local transitive deps.
But transitive :local/root
s are trickiest when working and changing stuff in such a local repo.
As opposed to a git dep being cloned once and not touched afterwards. So maybe I worry too much?