depstar

Discussion around https://github.com/seancorfield/depstar
2020-12-18T17:59:23.235800Z

hi all...just playing with practically and depstar for uberjar, and for somer eason, it seems that dependency libs don't get included in uberjar... Eg. I created sample project via "app" template, added "omniconf" lib via to deps.edn as :

:deps  {org.clojure/clojure    {:mvn/version "1.10.1"}
         com.grammarly/omniconf {:mvn/version "0.4.2"}}
and when I build uberjar via practicalli's :
clj -X:project/uberjar :main-class me.marcinko.woah :jar woah-uber.jar :verbose true :aot false
in verbose output, it doesn't show that omniconf lib got included:
Building uber jar: woah-uber.jar
src
src/me/marcinko/woah.clj
resources
resources/.keep
/home/vmarcinko/.m2/repository/org/clojure/clojure/1.10.1/clojure-1.10.1.jar
/home/vmarcinko/.m2/repository/org/clojure/core.specs.alpha/0.2.44/core.specs.alpha-0.2.44.jar
/home/vmarcinko/.m2/repository/org/clojure/spec.alpha/0.2.176/spec.alpha-0.2.176.jar
/usr/local/lib/clojure/libexec/exec.jar

Processing pom.xml for {me.marcinko/woah {:mvn/version "0.1.0-SNAPSHOT"}}

2020-12-18T17:59:42.236300Z

Anyone knows what I'm doing wrong?

2020-12-18T18:01:02.236800Z

later when I tried to start the jar file, I got following of couse:

2020-12-18T18:01:40.237100Z

Caused by: Could not locate omniconf/core__init.class, omniconf/core.clj or omniconf/core.cljc on classpath.

seancorfield 2020-12-18T18:05:07.238Z

@vmarcinko What is the :project/uberjar alias exactly? I seem to recall @jr0cket fixed a bug recently with his deps.edn in that area...

2020-12-18T18:06:04.238300Z

;; Uberjar archive of the project, including Clojure runtime
  ;; clojure -X:project/uberjar :main-class domain.application
  ;; clojure -X:project/uberjar :jar '"project-name.jar"' :main-class domain.application
  :project/uberjar
  {:replace-deps {seancorfield/depstar {:mvn/version "1.1.126"}}
   :exec-fn      hf.depstar/uberjar
   :exec-args    {:jar        "uber.jar"
                  :aot        true
                  :main-class project.core}}

seancorfield 2020-12-18T18:07:36.238600Z

You need to update to his latest then.

👍 1
2020-12-18T18:08:55.239500Z

ok, now i checked, definitely bug with practically, since when I used :uberjar alias from generated project's deps.edn, everything worked fine..

seancorfield 2020-12-18T18:20:35.245300Z

It should be :extra-deps there not :replace-deps

practicalli-john 2020-12-18T18:20:38.245400Z

@vmar FYI, the :project/uberjar briefly has :replace-paths [ ] and replace-deps added to it. This was a bug and has been fixed now. It was added in error as a similar tool recommended busing this setting and it was also applied to depstar in error. Sorry for the confusion

seancorfield 2020-12-18T18:21:52.248Z

depstar 2.0 will work with :replace-deps (I'm changing how it computes the basis)

2020-12-18T18:22:47.248800Z

@jr0cket Actually, I feel bad to written the last comment I just removed... I very appreciate all your contribution to clojure community, it was just typical unbfortunate situation when newbie is starting to experiment with some new tech, and accidetally stumble at the very beginning of playing with it to a bug, but the newbie in that moment thinks he has done something wrong

2020-12-18T18:23:34.249800Z

When one gets experienced, then he knows this stuff worked before, so there's a good chance a lib got broken etc...

practicalli-john 2020-12-18T18:24:32.251200Z

I am always an @ mention away if you have issues with my work. Nothing is perfect and I can't fix anything if I don't know about it 😁

2020-12-18T18:25:13.252500Z

no problem...actually, I never used depstar before so I assumed it was problem there, so that's why I came to this channel instead of pinging you

2020-12-18T18:25:53.254Z

but just when I was typing here, then I realized I haven't tried depstart directly, so ...

practicalli-john 2020-12-18T18:26:00.254200Z

@seancorfield good to know about V2 of depstar, I will keep an eye out for it. I guess I was too bleeding edge with the replace change 😆

practicalli-john 2020-12-18T18:28:56.256800Z

I missed it, but it might be in the Zulip history 😁 I won't look...

seancorfield 2020-12-18T18:32:28.260700Z

For a bit of background on that: V1 uses the current/runtime basis (effectively) by just looking at what is on the current classpath and that's what goes into the JAR (excluding depstar itself). That's why it also has a :classpath option, so you can explicitly override the list of things it will put in the JAR. This is both simple and easy: when you ask depstar to build a JAR, it will use whatever dependencies you've asked for (via aliases to the CLI), so it needs no additional options to control how to build the basis. The downside is that depstar cannot have any other dependencies because it wouldn't know how to exclude them from the JAR (and might end up conflicting with versions of those same dependencies you are trying to use in the project). V2 will compute the project basis using tools.deps.alpha, which means that depstar can have any dependencies it wants and, using :replace-deps, it won't "leak" into the JAR file. However, that means that it will need options to figure out what aliases need to be used when reading/merging the various deps.edn files, and also potentially, an option to ignore the user-level deps.edn file (like the CLI's -Srepro option). It will also mean you can't just build a JAR from deps provided on the command-line.

seancorfield 2020-12-18T18:33:15.261200Z

(there's a 2.0 milestone in the depstar repo which has information on this)

👍 2
practicalli-john 2020-12-18T18:46:42.261400Z

Thank Sean, much appreciated