This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-12-13
Channels
- # adventofcode (51)
- # announcements (1)
- # babashka (7)
- # beginners (45)
- # berlin (2)
- # bristol-clojurians (1)
- # calva (38)
- # cider (2)
- # clara (25)
- # clj-kondo (2)
- # cljs-dev (25)
- # cljsrn (3)
- # clojure (112)
- # clojure-dev (6)
- # clojure-europe (5)
- # clojure-nl (1)
- # clojure-spec (15)
- # clojure-uk (93)
- # clojurescript (29)
- # clojutre (2)
- # core-async (78)
- # cursive (24)
- # datomic (29)
- # figwheel-main (1)
- # fulcro (50)
- # hugsql (1)
- # hyperfiddle (1)
- # luminus (1)
- # malli (26)
- # off-topic (40)
- # portkey (12)
- # reagent (22)
- # ring-swagger (1)
- # shadow-cljs (56)
- # spacemacs (24)
- # tools-deps (68)
Hi all - I’m sure this has been asked before but I just can’t find the answer. Is there a way to signal in my deps.edn that one of my deps is a bom and not a jar?
Or, actually more specifically, I seem to have problem with a bom as transitive deps.
You may be right, but bom does have a relevant meaning here.
Hey all - actually noticed some updated support for this. Switched to the latest tools.deps and the transitive dep was resolved.. yeah - I was talking about a “bill of materials” dep..
What route should I take to get the equivalent of lein uberjar
with :aot :all
using the Clojure CLI tools?
We use depstar
at work to build uberjars for production deployment and we do not AOT anything.
Thanks for replying @U04V70XH6. Along with deploying our uberjar to ECS within a docker image, we also invoke it multiple times within our CI pipeline. My principle motivation was to shave some time off the CI runs, and additionally plain curiosity around why the facility wasn't being supported yet.
Fair enough. If you (manually) create a classes
folder in your project and add it as an :extra-paths
entry when building your uberjar, you can run clojure -e "(compile,'my.entry.point)"
as a way to compile the entry namespace (`my.entry.point` here) and its transitive deps.
depstar
tries hard to avoid messing with your project or your classpath: it just packages up whatever you tell it to, using the classpath as constructed by clojure
using whatever options you've provided. Because compile
requires that classes
exists -- or else you can use binding
to tell the compiler to put class files somewhere else, that must still exist -- and that the output path of the compiler needs to be on the classpath for depstar
to include those files, it just doesn't seem like something depstar
itself should try to do.
Note that the depstar
README does address this case https://github.com/seancorfield/depstar in terms of Main-Class
in the manifest but it stops short of explaining specifically how to compile code and get the classes onto your classpath.
if you have an :aliases
alias in ~/.clojure/deps.edn and one in your project deps.edn, it seems they are not merged?
e.g. putting:
:babashka {:classpath-overrides {org.clojure/clojure nil
org.clojure/spec.alpha nil
org.clojure/core.specs.alpha nil}}
in ~/.clojure/deps.edn
and in the project.deps::
:babashka {:classpath-overrides {my_gist_script nil}}
does not seem to mergeThey merge-with merge at the aliases level iirc
I’m sure this has been asked before, but can’t seem to find it. When within a running clj repl, is it possible to resolve new deps; kind of like boot-clj set-env! ?
there's a speculative feature called add-lib
in a branch for this
(sha in that article is out of date)
where do I find the correct sha?
whatever the newest sha in the add-lib branch is generally https://github.com/clojure/tools.deps.alpha/tree/add-lib
it was pretty far out of date so I just merged it in 19d197ab221d37db750423eb970880cb87a91100
thanks
Wow - this is great! Thanks Alex!
I think we will probably add this, but some of the details are likely to change
We use depstar
at work to build uberjars for production deployment and we do not AOT anything.
@codeasone why do you want to AOT?
it is perfectly reasonable to AOT a final uberjar for deployment
I asked this question few months ago, but since that time, did anyone write a lein-ancient equivalent for tools.deps?
There's depot and deps-ancient (I've only used depot). https://github.com/clojure/tools.deps.alpha/wiki/Tools#deps-management
We've been using Depot very happily (although I've recently developed a bash script that does crazy stuff with clojure -Stree
and a synthesized deps.edn
file to get outdated deps in a way that suits us better)
@U04V70XH6 care to share the bash script? I'd be curious if I can port it to babashka and make a nice example out of it 🙂
Trust me when I say it's "crazy stuff" -- and it relies very heavily on our custom build
shell script that drives our use of clojure
...
The TL;DR is that it runs clojure -Stree
to a file, runs that through sed
etc to produce a temporary deps.edn
with "RELEASE"
for all of the dependency versions (that were :mvn/version
explicit versions), then runs clojure -Stree
on that, and then it compares the output of both trees, with some fudging to account for only the top two levels of dependencies...
Running Depot reliably on our huge monorepo and getting all the outdated deps that matter and avoiding the noise from transitive deps that I don't care about was very tricky, especially since we use CLJ_CONFIG
to setup a baseline deps.edn
with :override-deps
for a lot of stuff...
...any t.d.a. tooling that tries to read and process deps.edn
files in isolation can run into problems with our setup -- tooling that uses the same process to read/merge the environment as clojure
itself does works better for us.
@U04V70XH6 https://github.com/borkdude/babashka#list-outdated-maven-dependencies Thanks for the idea 🙂
Wow, hahaha!! Important to note that your code won't work with any deps.edn
that relies on ~/.clojure/deps.edn
(or CLJ_CONFIG
) to override/default any deps... 🙂
yeah, this is just a quick sketch which should be tuned to the needs of the scripter
It just goes to show what can easily be done -- and it would work for "most people" I suspect.
One could even use this for project.clj by just parsing the deps from it, generate a deps.edn and then run this script
@ghadi I’m reporting back on yesterday’s tools.gitlibs
OOME issue, which was seen when downloading large repo dependencies: bumping JVM Xms from 256m to 512m seems to have worked. I’ve not seen a failure yet, anyway. Thanks again for your instantaneous help.
seems pretty weird that jvm wouldn't grow to 512m
I wonder if you're getting client jvm by default instead of server
Indeed - I had wondered myself why this would be so; I shouldn’t need to babysit the jvm (?); but it does seem to be the server jvm:
$ java -version
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1ubuntu1~16.04.1-b10)
OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
using same version locally, I get an initial of 256m and max of 4g with no settings
with -Xms256m as set in the script, I see the same
however, the max is dependent on the available ram - I think it's 1/4 total ram by default
I agree that it is odd. This is on a Travis CI instance: Ubuntu 16.04.6 LTS (xenial). We hope to move to more recent versions of the JVM and Ubuntu soon. We’ve never seen this issue on developer machines (macos). The CI environment is more memory constrained than our dev machines. 7.5 GB, I think; but some of that memory is taken up by docker processes, as well as a JVM database process.
Maybe the Travis CI instance has 1G RAM default?
certainly could be something like that