Fork me on GitHub
#tools-deps
<
2018-05-05
>
slipset08:05:04

Reason I’m asking is sort of at least twofold: 1) If it’s sort of the same, is there anything to be learned by the clj-refactor impl 2) If it’s sort of the same, can add-lib be used as a replacement for the clj-refactor impel so we get consistent behavior. 3) most likely just an off by one error

dominicm08:05:32

I'm certain it's almost entirely the same. I expect that in a few months this implementation will find it's way into refactor-nrepl.

hagmonk19:05:28

@alexmiller Riddle me this: how does one add a maven dep and the corresponding sources and javadoc jars to the classpath? (needed for cider javadoc to work)

Alex Miller (Clojure team)19:05:58

Currently you can only have one artifact per library

Alex Miller (Clojure team)19:05:39

I’m not opposed to supporting it, just trying to figure out how

dominicm19:05:00

@alexmiller would treating it as a unique library be insufficient?

hagmonk19:05:33

I'd propose clojure.tools.deps.alpha/merge-alias-rules be extended with some way to delegate merge strategy to the extension type

hagmonk19:05:47

Uh, maybe not, that is only used to merge the same map key between different deps.edn sources

hagmonk19:05:13

maybe clojure.tools.deps.alpha/resolve-deps instead - when merging :extra-deps into :deps

hagmonk19:05:05

you still end up spitting out a map though, perhaps the key of that map needs to change from being the dependency path, to an opaque composite key that represents "a unique artifact". The dep path itself could move into the value (during resolution, not in deps.edn itself)

Alex Miller (Clojure team)19:05:42

That’s only used for alias types, which are not extensible

Alex Miller (Clojure team)19:05:23

The merge-alias-rules that is

Alex Miller (Clojure team)19:05:08

Treating it as a unique library isn’t possible as the group/artifact is used for resolution

Alex Miller (Clojure team)19:05:50

This needs more thought and I consider it a lower priority than other stuff on the plate

👍 4