This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-09-17
Channels
- # 100-days-of-code (4)
- # announcements (4)
- # aws (2)
- # beginners (88)
- # cider (1)
- # cljsrn (9)
- # clojure (126)
- # clojure-conj (4)
- # clojure-dev (8)
- # clojure-greece (1)
- # clojure-italy (37)
- # clojure-nl (3)
- # clojure-spec (13)
- # clojure-uk (91)
- # clojurescript (392)
- # clojurewerkz (1)
- # clojutre (10)
- # core-async (6)
- # cursive (5)
- # data-science (1)
- # datomic (41)
- # emacs (21)
- # events (1)
- # figwheel-main (52)
- # fulcro (2)
- # hyperfiddle (4)
- # jobs (3)
- # jobs-discuss (9)
- # luminus (3)
- # lumo (9)
- # mount (1)
- # nyc (1)
- # off-topic (73)
- # other-languages (6)
- # pedestal (8)
- # portkey (2)
- # re-frame (9)
- # reagent (8)
- # rum (17)
- # shadow-cljs (38)
- # sql (19)
- # tools-deps (18)
- # yada (4)
TDEPS-74 seems to get to the heart of it. OK, I guess I'll go vote for it!
@alexmiller @arrdem was offering a patch for the local/root issue I believe...
well I’ve thought about it a lot and haven’t come up with a solution I’m happy with
If the tools.deps reader converted paths (from :paths
, :extra-paths
, and :local/root
-- and maybe others?) from relative to absolute, based on the location of the deps.edn
file in which they occur, would that solve the problem?
I don’t think so
(or, rephrased, at what point does tools.deps convert paths to absolute ones -- they are absolute in the classpath at the end)
the extension does it when it resolves the paths for a dep
but it’s really about what the “current directory” means when you are resolving a transitive dep by relative path - currently nothing is shifting that context so you always have the root dep context
Ah, and paths can be in both the system deps and the per-user deps and of course you don't want those resolved against the file they're defined in... yeah...
And by the time you've collapsed all the deps down, you've lost that context, right?
yeah. we actually conceived local deps primarily as working primarily with absolute paths - all the stuff people are doing with relative paths and monorepos is somewhat emergent
So for https://github.com/fundingcircle/lein-modules, we added a “//” notation somewhat stolen from pantsbuild - the idea was that paths which were not “//” prefixed were treated as relative and just passed around, “//” prefixed paths were treated as being absolute with respect to the project.clj the path occurred in - for us implicitly the “root” project.clj of the repo which emulates the meaning of “//” in Google Blaze derived systems where “//” is repo root when referring to build target names.
Yeah, I’m not doing that :)
Perhaps a more serious option here would be #file EDN extensions... maybe not suitable for general purpose but perhaps useful for us.
None of that seems necessary to me
I think the intent of this kind of setup is clear as is, the questions are in the implementation