This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-04-20
Channels
- # announcements (1)
- # asami (6)
- # babashka (21)
- # beginners (19)
- # calva (44)
- # circleci (3)
- # clj-http (3)
- # clj-kondo (44)
- # clojure (24)
- # clojure-australia (1)
- # clojure-czech (1)
- # clojure-europe (50)
- # clojure-france (5)
- # clojure-germany (1)
- # clojure-nl (2)
- # clojure-spec (8)
- # clojure-uk (8)
- # clojurescript (161)
- # datomic (4)
- # fulcro (7)
- # graalvm (8)
- # heroku (4)
- # lambdaisland (4)
- # lein-figwheel (5)
- # lsp (48)
- # malli (21)
- # meander (15)
- # off-topic (35)
- # polylith (2)
- # re-frame (21)
- # react (22)
- # reagent (13)
- # reitit (6)
- # remote-jobs (1)
- # reveal (3)
- # ring (3)
- # shadow-cljs (37)
- # testing (2)
- # tools-deps (10)
- # vim (18)
- # vrac (1)
- # xtdb (17)
I have a transitive dependency to an artifact with a reported security vulnerability. With Leiningen, I'd add a :managed-dependencies
entry for a version of that artifact where that vulnerability has been fixed. What's the "right" way to do this with deps.edn
? Just add a :deps
entry?
@flowthing I think so yes, tools.deps will pick the newest version possible that is required in the deps tree
Hi all. Is there a way of referencing an alias (or indeed multiple aliases) in a git coordinate in a deps.edn file? The background is https://clojurians.slack.com/archives/C03S1KBA2/p1618904583308100 but essentially, I’d argue this approach might foster modularity and composability - permitting declaration of faceted dependencies. An example might be a repository aligned to a business domain with core code that can be used as a library, but an alias providing, say, ring handlers or graph resolvers that clients can explicitly opt-in or out of, to bundle the functionality into a server application. Possible with maven - by building different artifacts - and with a multiple repository model. Am I barking up wrong tree?
It looks as if the polylith type approach might work for this - although I do still think git coordinates that could include specific alias(es) and nested directories would do much to configure the exact building blocks to be used to build artefacts from a menu of common libraries / components.
@mark354 I had something like this with boot: https://github.com/borkdude/boot-bundle But nowadays we just use some EDN to list the deps + fixed versions we need and use a babashka script to update our deps.edn. This is very fast and only needs to happen when we update a dependency.
Another approach might be to just make a library which depends on other libraries and use that as the managed dependency, tools.deps will always use the newest versions of a lib in a dependency tree, I think
Thanks! I never used boot as I migrated very quickly from lein to deps when I started with clojure last year. A small standalone library would be fine too except for the potential explosion of repositories named xxx-library xxx-server xxx-graph-api etc…
(off topic, but slightly related:
Found another good use for fs/modified-since
(a new function in babashka.fs):
https://gist.github.com/borkdude/35bc0a20bd4c112dec2c5645f67250e3#file-1-bb-edn-L2-L5
We rebuild our deps.edn from a template when any relevant files on which it depends changes, when invoking any task.
)
It looks as if the polylith type approach might work for this - although I do still think git coordinates that could include specific alias(es) and nested directories would do much to configure the exact building blocks to be used to build artefacts from a menu of common libraries / components.