This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-01-13
Channels
- # admin-announcements (1)
- # announcements (40)
- # aws (2)
- # babashka (46)
- # babashka-sci-dev (106)
- # beginners (31)
- # cider (5)
- # circleci (2)
- # clj-kondo (48)
- # clojure (118)
- # clojure-belgium (1)
- # clojure-chicago (3)
- # clojure-europe (19)
- # clojure-ireland (3)
- # clojure-losangeles (2)
- # clojure-nl (2)
- # clojure-spec (10)
- # clojure-uk (4)
- # clojurescript (18)
- # community-development (5)
- # core-async (159)
- # cursive (16)
- # datomic (16)
- # etaoin (1)
- # fulcro (21)
- # funcool (14)
- # graalvm (5)
- # gratitude (4)
- # holy-lambda (28)
- # jobs (1)
- # jobs-discuss (1)
- # kaocha (1)
- # lsp (12)
- # malli (21)
- # meander (12)
- # music (1)
- # off-topic (8)
- # portal (5)
- # react (18)
- # reitit (1)
- # releases (4)
- # remote-jobs (1)
- # shadow-cljs (56)
- # timbre (4)
@niwinz: Thanks for the reply, I didn’t mean to hassle you and this isn’t particularly urgent for me… As you say I can force the dep myself. I’ve just been on a bit of a trawl through transitive deps recently in light of log4shell and pushing such patches as far upstream as I can; largely to ensure the tests are also run upstream too. I’ve come across a few moribund projects along the way, so have been trying to help highlight them and find maintainers (or take it on myself) e.g. see https://github.com/clj-commons/meta/issues/63 so I was mainly just wondering what the status of buddy is, as it’s obviously an important dep for a lot of people.
buddy is just stable dep, I have no plans to develop more functionality unless this is very very important, we use it ourselves for many purposes
just for context, i'm right now very busy developing http://penpot.app that is built with clojure
I agree it’s stable; it’s great 🙇 I was wondering a few things though… 1: I have been adding this github action to some of my projects: https://github.com/nnichols/clojure-dependency-update-action Which scans deps on a cron cycle and issues PRs (which will then run your tests etc) when upstream deps are bumped. This could help find any future CVEs in things like cheshire. I was thinking it might be worth adding something like this. 2. It being split into multiple deps makes sense; but it does make testing this stuff harder than it needs to be. I was wondering whether there might be any appetite in moving it into more of a mono-repo (but multi dep project); possibly rewired to use tools.deps/tools.build. It might help ensure all the tests can be run against changes across all repos before they’re pushed in an automated way.
Yeah totally I appreciate that time is a big problem to maintaining and testing this stuff; and more automation can help make sure simple stuff like this is kept upto date, without a lot of effort on your part. Once it is in place of course