This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-01-10
Channels
- # announcements (15)
- # bangalore-clj (1)
- # beginners (207)
- # calva (22)
- # cider (4)
- # clara (73)
- # cljs-dev (7)
- # cljsrn (4)
- # clojure (125)
- # clojure-dev (38)
- # clojure-europe (2)
- # clojure-india (11)
- # clojure-italy (11)
- # clojure-nl (14)
- # clojure-russia (22)
- # clojure-uk (32)
- # clojurescript (30)
- # cursive (11)
- # datavis (2)
- # datomic (14)
- # editors (3)
- # emacs (3)
- # hyperfiddle (4)
- # juxt (13)
- # klipse (1)
- # luminus (5)
- # nrepl (7)
- # off-topic (9)
- # overtone (13)
- # portkey (1)
- # re-frame (15)
- # reagent (13)
- # ring (30)
- # schema (4)
- # shadow-cljs (108)
- # spacemacs (8)
- # specter (3)
- # sql (2)
- # testing (11)
- # tools-deps (21)
- # unrepl (4)
Thx @alexmiller. While I’m at it, we’ve been bitten by https://dev.clojure.org/jira/browse/TDEPS-74 (deps transitivity issue involving :local/root
). Currently the scenario whereby project foo
depends on module a
of project bar
using bar {:git/url "
and bar.a
depends on siblings module bar.b
using {b {:local/root "b"}}
doesn’t work. @matthias.margush has put together a patch which solves the issue (more info on the ticket), if you have some time to look at it that would be great. We’re not far from being able to switch over to tools.deps for several multi-modules projects.
yeah, there are several issues with the path stuff and I don’t think the change there is sufficient to handle the real scope of the issues
That makes sense - it did seem like the way coordinate specifiers interact could use some hammock time overall.
some of those intersect with other problem areas (config file management)
Hi Alex. Reading through these in more detail, it looks fixes could potentially be bundled together with a fix for TDEPS-74... they are closely related, right? If it would be helpful at all, I'd be willing to take a look at these in context of the patch I started for TDEPS-74.
I’d say it’s unlikely I’m going to look at this set of things this week
Oh yeah, not expected. Just want to get it on the radar. tools.deps really opens up the ways that we can organize work across teams, and thanks for the work you all are doing on it.
One thing I noticed personally was that transport, location and manifest type are different things that relate and interact, but don’t map conceptually one to one to how extensions are dispatched.
transport and location aren’t uniform dimensions for procurers
manifest types are something that extensions dispatch on
Yeah - there are two layers of multimethods
I think possibly related to your comment about uniformity of dimensions - a capability I’d like to be able to support for our engineers is to checkout a git/deps dependency locally while working on a cross cutting feature. External tooling could support this well enough for example by transforming a git coordinate to a local one in the local work area.
But the differences in the set (& maybe the semantics) of dimensions make the creation of tooling more bespoke than needed. I think specifically in this use case it would help for the :deps/root
to work the same between git coordinates and local coordinates. (Unless that’s already the case and I misread the code.)
So such a tool needs to know the dimensions available and how they are used for each kind of coord.
@alexmiller i’m interested in learning more about how to download jars without using maven/ivy - do you know of anything that talks about how that works?
@duncanmak If you know the URL of the JAR in the repository, you can just download it via any means -- such as curl
at the command line, or programmatically using URI and byte input streams etc.
(unless the repo is secured and then you'll need to factor in auth credentials)