Fork me on GitHub
#depstar
<
2020-11-08
>
rickmoynihan16:11:58

@seancorfield So where do you think this PR is best implemented? https://github.com/slipset/deps-deploy/issues/20 My feeling was it was better pushed upstream into either depstars library building phase or a separate pom-update tool. I’m guessing you’d rather the later.

seancorfield17:11:42

It belongs more with depstar than at deployment because the POM etc inside the JAR needs it. I'll point out that if you use -X with depstar you get t.d.a inside your JAR, which is probably not what you want.

rickmoynihan10:11:48

Why would I get t.d.a inside the JAR when calling with -X? I’m pretty sure the t.d.a lib itself isn’t included on the running JVMs classpath unless you include it explicitly as a dependency, because the CLI tools do a JVM trampoline after the resolve/make/cache classpath phases.

rickmoynihan10:11:39

Confirmed with:

(ns foo.bar)

(defn class-path [_]
  (println (System/getProperty "java.class.path")))
And:
clojure -Sdeps '{:paths ["src"]}' -X foo.bar/class-path
src:/Users/rick/.m2/repository/org/clojure/clojure/1.10.1/clojure-1.10.1.jar:/Users/rick/.m2/repository/org/clojure/core.specs.alpha/0.2.44/core.specs.alpha-0.2.44.jar:/Users/rick/.m2/repository/org/clojure/spec.alpha/0.2.176/spec.alpha-0.2.176.jar:/usr/local/Cellar/clojure/1.10.1.716/libexec/exec.jar

seancorfield15:11:56

Alex has fixed that part then. But you do get clojure/1.10.1.716/libexec/exec.jar on your classpath.

rickmoynihan15:11:12

Yeah, though that has no transitive dependencies other than clojure at least 🙂

rickmoynihan15:11:42

And I’m guessing it’s guaranteed that it won’t ever have any transitive deps

seancorfield15:11:22

Dunno. As far as I'm aware, it's undocumented and "just an implementation artifact".

seancorfield15:11:00

(I suspect it may become part of Clojure "core" in 1.11 the way things are going)

rickmoynihan15:11:04

It is; but it was presumably added to prevent the classpath being polluted by t.d.a deps; which are likely to change over time etc

seancorfield17:11:22

Changing the version alone in a POM is also probably not what you want since tooling also relies on the SCM tag.

rickmoynihan10:11:39

It’s pretty easy to include overriding the SCM tag too

seancorfield17:11:39

This is not a simple problem to solve correctly.

seancorfield18:11:17

I would also say that the "correct" approach here would be to have some sort of templating system that allows users to have stuff like ${version} in pom.xml and have depstar make substitutions, based on command-line arguments. But depstar made a very deliberate choice to have no dependencies, and to work (by default) from exactly the supplied classpath. Which means that whatever command-line arguments are for this, depstar would have to continue to parse them itself (rather than relying on tools.cli, for example, as clj-new does (because it already has a load of dependencies). And while the -X approach with depstar would allow for that easily, you'd then get t.d.a in your (uber) JAR file which might be problematic.

seancorfield18:11:02

All of this has to be taken into account -- and, frankly, I'd rather wait and see what tools.build does because I'm pretty sure this is a solved problem in tools.build, based on some of the workflows Alex has talked about.

rickmoynihan10:11:31

Again I only think this needs to be taken into account because of uberjars. If we were to hypothetically make depstar only about uberjars and make a new library only about jars, uberjarring concerns wouldn’t be driving library making concerns.

seancorfield15:11:09

Fair enough. I'll give it some thought. But, still, I'm not going to expend too much effort with tools.build on the horizon.