This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-03-09
Channels
- # aleph (1)
- # announcements (4)
- # asami (6)
- # babashka (45)
- # beginners (19)
- # biff (3)
- # calva (35)
- # cider (4)
- # clojars (5)
- # clojure (117)
- # clojure-art (3)
- # clojure-denmark (2)
- # clojure-europe (89)
- # clojure-gamedev (5)
- # clojure-nl (4)
- # clojure-norway (17)
- # clojure-spec (3)
- # clojure-uk (5)
- # clojurescript (84)
- # conjure (13)
- # datomic (11)
- # emacs (2)
- # figwheel (2)
- # fulcro (16)
- # graphql (5)
- # honeysql (7)
- # introduce-yourself (1)
- # lsp (86)
- # malli (16)
- # music (1)
- # off-topic (2)
- # pathom (14)
- # polylith (28)
- # re-frame (11)
- # reagent (23)
- # releases (1)
- # reveal (19)
- # shadow-cljs (72)
- # spacemacs (13)
- # sql (1)
- # test-check (3)
- # timbre (4)
- # tools-deps (45)
- # vim (18)
I’m setting :https://github.com/nextjournal/clerk/blob/9a62fe7dd40850cd20b9b1afb7c78058da6de600/deps.edn#L43. And I’m getting a https://github.com/nextjournal/clerk/runs/5476651483?check_suite_focus=true. Anybody know how to fix this? Relevant line is :jvm-opts ["-Dclerk.resource_manifest={\"/js/viewer.js\" \"
You probably need different embedded escaping/quoting on windows
That opt gets put into a .jvm file in .cpcache, then pulled out of the file and put on the command line, where you might need “”” around the embedded opts
embedded opts is the edn map, ie the value of the prop? tried various things so far without sucess
was able to get CI green by switching to bb clojure
though cc @U04V15CAJ
Hi! Basic question here.
I understand I can get the classpath from the top level :deps
with clj -Spath
. Also I can get the classpath from an alias with clj -Spath -A:my-alias
, and can merge these with clj -Spath -A:my-alias1:my-alias2
.
How can I merge the classpath from the top level :deps
with a classpath from an alias?
Depending what's in the alias that is what you get - aliases modify the deps classpath. Can you give more detail about what's in the aliases, what you get, and what you want?
Thanks!
Considering this deps.edn
:
{:deps {dep/dep-root {:local/root "dep-root"}}
:aliases {:my-alias1 {:deps {dep/dep-1 {:local/root "dep-1"}}}
:my-alias2 {:deps {dep/dep-2 {:local/root "dep-2"}}}}}
When I’m running this clj -Spath -A:my-alias1:my-alias2
, I can get a classpath with dep-1
and dep-2.
I would like to get a classpath which has dep/dep-root
and eg dep/dep-1
@UGSM2S2CS Use :extra-deps
in your aliases instead of :deps
. The former is additive. The latter is not.
No. You'd need two versions of the alias, I think, one with :extra-deps
and one with :replace-deps
(or just :deps
, but I think the former is clearer).
I guess my question would be: Why? What problem are you really trying to solve?
Perhaps there's a better approach...
You could have :deps {}
and then under :aliases
have :default {:extra-deps {dep/dep-root ...}}
etc and explicitly specify the :default
alias when you need those "root" deps.
yes, that’s what I ended up with, it works.
[well. I have an ancient Java project using fairly complex ant build with xdoclet/ejb2/custom codegen/etc where the classpath is hardcoded into the build files in various places using only local jars.
I wanted to start to use some Clojure here.
I didn’t want to/cant replace the whole build and I don’t want to duplicate the dependencies, so I figured that in the ant config wherever a custom classpath is used, i outsource to deps.edn
with an alias and call clj -Spath -A:alias
from ant to calculate the classpath.]
Is there a way to have :override-deps
at the top level of my deps.edn file? It seems like it only works when it's put inside an alias?
I'm trying to override Netty dependency versions (ultimately I'd like to use the Netty BOM) but for now I can just write out each dependency. But I'd prefer not to have all of our clojure
commands have to include a -A:defaults
alias on every command. It feels like it would be quite easy for people to accidentally get the wrong Netty version.
no, that's not a feature
if you're trying to override the version of a transitive dep, you can add :exclusions to the top-level dep, then add the transitive dep at the top with whatever version you want
lmk if that doesn't make sense
> if you’re trying to override the version of a transitive dep, you can add :exclusions to the top-level dep, then add the transitive dep at the top with whatever version you want
If this isn’t the problem :override-deps
is meant to solve, what problem is it meant to solve?
it's meant to solve that problem when you apply an alias
that is, a conditional override
if I'm reading the original request right, the goal is non-conditional override
There are a bunch of different libraries all with dependencies on various Netty components. I want to specify that if any of them pull in any of the Netty dependencies they should get the version I selected, without actually adding a dependency on any extra Netty JARs that aren't needed
yeah, so there is no place to put that right now - you need to exclude on each top-level dep that includes those transitive deps
i.e. if our Redis library adds a new dependency on netty-buffer
in a new version, I want to have already specified which version of netty-buffer will get pulled in, without actually including it in the JAR
this is something that's been requested (global exclusions / global overrides)
When searching I found I'd asked the same question a few years ago: https://ask.clojure.org/index.php/8440/equivalent-of-leiningens-managed-dependencies-in-deps-edn
still haven't decided how this should best be done in deps.edn
FWIW @U051KLSJF we ourselves just eat the annoyance of having a required alias
I read that ask question as being slightly different (managed deps being - what dep should I use if version is not supplied)
vs force the version to be something regardless of what transitive deps use
:managed-dependencies
in Leiningen provides overrides for version resolution. I don't think it relies on the version not being provided in the main :dependencies
vector, but that is a related feature
I think it’s a direct analog to maven/pom dependencyManagement
https://maven.apache.org/pom.html#dependency-management
well, I may misunderstand either maven's dependencyManagement or lein's expression of it but I think of managed deps as default versions that can be overridden
> 1. It does not actually introduce any dependencies to your project. It only says, "hey leiningen, if you encounter one of these dependencies later, here are the versions that you should fall back to if the version numbers aren't explicitly specified."
I think this means if the version number isn't explicitly specified in your :dependencies
file. Which could either be you included the dependency with no version number, or it was a transitive dependency
It does in fact prefer :managed-dependencies versions to those of transitive deps, because the effect is seen in the resulting classpath. This is why this is perfect for addressing CVEs
well, I'll think about it more and maybe look at it Friday, thx for the poke