depstar

Discussion around https://github.com/seancorfield/depstar
2020-11-08T16:42:58.098Z

@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.

seancorfield 2020-11-08T17:25:42.102700Z

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.

2020-11-10T10:14:48.114700Z

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.

2020-11-10T10:18:39.114900Z

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

seancorfield 2020-11-10T15:47:56.115800Z

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

2020-11-10T15:51:12.116Z

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

2020-11-10T15:51:42.116200Z

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

seancorfield 2020-11-10T15:52:22.116400Z

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

seancorfield 2020-11-10T15:53:00.116600Z

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

2020-11-10T15:53:04.116800Z

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

seancorfield 2020-11-08T17:27:22.104200Z

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

2020-11-10T10:20:39.115200Z

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

seancorfield 2020-11-08T17:27:39.104700Z

This is not a simple problem to solve correctly.

seancorfield 2020-11-08T18:01:17.109500Z

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.

seancorfield 2020-11-08T18:02:02.110500Z

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.

2020-11-10T10:23:31.115400Z

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.

seancorfield 2020-11-10T15:47:09.115600Z

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.