This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (17)
- # babashka (8)
- # beginners (71)
- # calva (28)
- # clj-kondo (36)
- # cljsrn (1)
- # clojure (232)
- # clojure-dev (3)
- # clojure-europe (13)
- # clojure-nl (14)
- # clojure-spec (9)
- # clojure-uk (11)
- # clojuredesign-podcast (3)
- # clojurescript (38)
- # core-async (3)
- # cursive (1)
- # datahike (4)
- # datomic (4)
- # fulcro (56)
- # graphql (1)
- # helix (3)
- # honeysql (5)
- # introduce-yourself (1)
- # kaocha (2)
- # lsp (67)
- # malli (7)
- # meander (2)
- # off-topic (1)
- # pathom (9)
- # re-frame (55)
- # reitit (3)
- # releases (8)
- # remote-jobs (12)
- # shadow-cljs (12)
- # sql (3)
- # tools-deps (55)
- # vim (5)
- # xtdb (3)
Just released: μ/log - v0.8.0 with a number of bug fixes and improvements: μ/log (Pronounced: /mjuːlog/) is a micro-logging library that logs events and data, not words! https://github.com/BrunoBonacci/mulog
We just released https://gitlab.com/yogthos/mastodon-bot v1.13.6 Bringing improved output and improved error & timeout handling https://social.meissa-gmbh.de/tags/mastodon https://social.meissa-gmbh.de/tags/twitter https://social.meissa-gmbh.de/tags/mastodon-bot
Just released Inertia-clojure - v0.2.3 https://github.com/prestancedesign/inertia-clojure:
• Explicit mime type for HTTP response to fix issue when deploying on services like AWS Api gateway, etc
• Refactor examples to use new
• Fix wrong page redirect after hot reloading
• Bump dependencies
Happy to announce a pre-release of the Clojure CLI 220.127.116.115 and tools.build - read lots more here: https://clojure.org/news/2021/07/09/source-libs-builds This is being provided for feedback and tire-kicking and there will likely be more changes before it becomes a release. Notably if you have been following the pre-releases, we've temporarily removed the multi-function execution support.
Fellow hackers, lately I have been using this zen way of managing my private monorepos, here it is now in the open: https://github.com/helins/maestro.clj Monorepos are often hard and besides Polylith, there aren't many great solutions. But Polylith, while great for some purposes, was too opiniated for my endaveours. This solution simply uses Deps aliases with a hint of Babashka magic. I find the result to be very flexible and amenable. I hope you'll find if useful. This a preview as well, so feedback and PRs welcome :)
This is super interesting! Babashka glues in so well . Once you know it's power you can really see that it's the missing piece to solve a lot of problems 🙌
At work we generate deps.edns from a base deps.edn (using babashka) which fills in the versions so we're using the same version of every lib in every project
My job uses Bazel for the caching/orchestration/querying, but defers to babashka for most of the “doing”
@U04V15CAJ I've tried having one deps.edn per project and tried to make things super local but I encountered 2 problems: a) classpath for transitive local dependencies was getting really messy, Deps can't pick up distant changes ; b) very spaghetti-like, hard to maintain a clear overview, get a sense of what is requiring what. Don't you have that kind of issues?
@UCFG3SDFV The overview comes from the generated deps.edns: what you see is what you get, it's no different than when you would have written the deps.edn manually. Same for local/root I think?
Not saying one approach is better than the other, just sharing what we did. I still have to digest what your project is exactly doing, but it seems like an interesting approach
Yup, just trying to better understand. So each projects gets its own
deps.edn file, right?
Suppose your monorepo has 3 internal libs that depend on each other using
:local/root: A -> B -> C. You are working on A. If you modify
deps.edn of B to add a dependency for instance, I think you are good. But if you modify
deps.edn of C (a transitive local dependency needed by A), then Deps can't detect it. You enter a cycle where you have to manually force recompute the classpath and even that might not be enough.
I don't know if that applies to your setup?
@U04V70XH6 I think I read about something like that on your blog but can't quite remember it
Yes, this is a problem of deps.edn in general and not of my setup specifically I think
So that's why I've been asking about using
clojure on a user specified dir in BB, but ended up avoiding that and settled on a global
deps.edn at the root of the monorepo. Then you never get that kind of problems and it just works.