This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-07-14
Channels
- # announcements (3)
- # babashka (189)
- # beginners (157)
- # calva (5)
- # cider (5)
- # clj-kondo (7)
- # cljdoc (34)
- # clojure (61)
- # clojure-dev (2)
- # clojure-europe (42)
- # clojure-nl (15)
- # clojure-poland (1)
- # clojure-spec (5)
- # clojure-uk (6)
- # clojured (2)
- # clojurescript (31)
- # clojureverse-ops (8)
- # component (2)
- # cursive (41)
- # datomic (15)
- # depstar (44)
- # figwheel-main (9)
- # fulcro (14)
- # holy-lambda (1)
- # inf-clojure (13)
- # introduce-yourself (1)
- # jobs (1)
- # lsp (98)
- # malli (12)
- # off-topic (12)
- # pedestal (1)
- # polylith (3)
- # re-frame (51)
- # reitit (4)
- # releases (1)
- # reveal (5)
- # shadow-cljs (3)
- # tools-deps (56)
- # vim (12)
- # xtdb (36)
https://github.com/seancorfield/depstar/releases/tag/v2.1.267 -- the README has been split up into proper documentation https://cljdoc.org/d/com.github.seancorfield/depstar/2.1.267/doc/getting-started and several new sections added (I'm particularly interested in feedback on the new documentation!).
This documentation is excellent! It sounds silly, but breaking it up into pages is somehow cognitively easier to digest. Also, the new comparison/integration with tools.build
is very useful.
Thanks, @U7XR2PZFW -- at some point I need to split clj-new
's docs up in a similar way (esp. since I just added a small piece about clojure -Ttools
to that readme!).
Would it be technically possible to native-image compile depstar? I'm tempted to do it
I've no idea and I have no interest in it -- I'm more concerned with the CLI tools functionality -- but if you, or someone else, wants to try producing a native image and can produce a script that will run it all in Docker images (so my machines don't need anything extra installed), I'd be happy to incorporate that into depstar
's assets on GitHub. I don't know how @U04V15CAJ handles this for his tools?
@UJ1339K2B in babashka there is an older version of depstar that I use to make uberjars for bb projects itself (you invoke it via bb uberjar
). This was before depstar switched to including tools.deps. Now that it includes tools.deps it's a bit harder, but not impossible.
I have a native version of tools deps here: https://github.com/borkdude/tools-deps-native-experiment
Which version of depstar is available in babashka? I really don't care much about new features 😄
it's not really a specific version, more like a snapshot of which I branched of at a certain point
Is depstar somehow exposed via public api in babashka?
I don't really understand the difference between deps.clj and tools-deps
Why do you want to have this native? If you want to compile Clojure files to .class files, you need a JVM anyway
I got a lot of integrations tests which require Clojure compilation. Startup of depstar is like 4-5 seconds which makes the pipelines quite slow in the end.
Why are you running tests after building JAR files?
Because I don't test Clojure code 😄 I test graalvm compiled binary
And, to answer your question about an API, you can use depstar
as a library already (in fact the latest docs should examples of using depstar
in a build.clj
script).
Kill me please guys
I'm stupid man
I did some profiling and I was suprised that regular depstar takes 6s to compile while on wrapped depstar in my script takes like 13 seconds. Turns out that I should not remove .cpcache 😕 before running depstar.
In hf.depstar.task/preprocess-options
there is a call to t/create-basis
that gets invoked even if you have a :basis
in the options map. I cannot work out if that is intentional or not.(https://github.com/seancorfield/depstar/blob/4e9964d5e56c384dad11bf2bf5809891e490db00/src/hf/depstar/task.clj#L23)
My problem is that I'm trying to pass a bespoke basis created with (t/create-basis {:extra {:mvn/local-repo "some-project-local-folder"}})
in order to do some dependency caching in a CI environment. But that call to t/create-basis
means that all deps are downloaded into ~/.m2
every time anyway.
> If :basis is provided in the initial options, that is returned as-is instead of calculating a new project basis.
from docstring of options-and-basis
indicates that it is a bug.
> Given an options hash map, if any of the values are keywords, look them up as alias values from the full basis (including user deps.edn
)
from docstring of preprocess-options
indicates that it is not.
In case it is a bug, I've opened a PR which hopefully fixes it: https://github.com/seancorfield/depstar/pull/96
Hmm, interesting. The reason for that specific call is to get all available aliases for resolving aliases-as-data so it takes your user deps.edn
into account whereas the other two uses (overall basis and compile-specific basis) do not.
I think what I'll do here is revert to just reading and merging the EDN files (and not actually compute the basis completely).
BTW, you specify :compile-aliases
it will calculate a new basis, just for compilation.
But with :compile-aliases
there's no way to add an option such as :mvn/local-repo
to the basis, right?
That would need to be in your deps.edn
as things stand today. If you don't need compilation to use a different basis to the one used for building the JAR, it wouldn't matter.
I think I will end up putting it in deps.edn
as you say, thank you. It seems a bit odd to me that the path to the m2 cache is so relatively inflexible – it can't be changed with aliases for example. With lein it could be configured with profiles. With maven it can be controlled with -Dmaven.repo.local
. But that's because of tools.deps.alpha, not depstar, of course.
By default, whenever depstar
builds a basis itself, it does it from (just) the project's deps.edn
file. If you feel you will need a custom basis for compilation, separate to the project's basis, open an issue requesting a :compile-basis
option and I'll add it.
I don't think that's what I want – all I want is to avoid downloading dependencies over and over again in my CI pipeline, and use the cached dependencies instead. It seems to me the best way to ensure that right now is to add :mvn/local-repo
to deps.edn
, which means that everybody needs to store the dependency cache in the same place as the CI machine.
I can call depstar with clojure -Sdeps '{:mvn/local-repo ".depscache/m2"}' -X:depstar/uberjar [...]
, but that'll only mean I pull depstar from the cache, not the deps used for the build.
Why can't you just cache the CI's ~/.m2
folder directly? That's what we do in CI.
Yes that would be the easiest, but as far as I know that's not possible. It's Gitlab CI btw, with the docker runner.
Hmm, BitBucket Pipelines lets you do it -- and it's pretty primitive compared to most other CIs 🙂
It probably has to do with the way it runs the build with docker – I guess the runner mounts the project dir in the container, and only has access to that dir, and the rest gets wiped when the ephemeral build container is removed
Could be. ISTR GitHub CI is also a bit like that. I haven't investigated any caching for my OSS projects yet...
OK, depstar
develop HEAD has the fix for that if you want to try it via :git/url
.