Fork me on GitHub

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!

👍 39
🎉 5
Michaël Salihi17:07:31

Just released Inertia-clojure - v0.2.3 • Explicit mime type for HTTP response to fix issue when deploying on services like AWS Api gateway, etc • Refactor examples to use new createInertiaApp helper • Fix wrong page redirect after hot reloading • Bump dependencies

👍 9
Alex Miller (Clojure team)17:07:31

Happy to announce a pre-release of the Clojure CLI and - read lots more here: 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.

🎉 100
🚀 16
pizzaspin 5
sheepy 8
🏗️ 8
Adam Helins17:07:21

Fellow hackers, lately I have been using this zen way of managing my private monorepos, here it is now in the open: 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 :)

babashka 16
🎉 25
oxalorg (Mitesh)19:07:33

This is super interesting! Babashka glues in so well babashka. 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

👍 16
babashka 2
nice 4

My job uses Bazel for the caching/orchestration/querying, but defers to babashka for most of the “doing”

Adam Helins20:07:31

@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

Adam Helins10:07:38

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

Adam Helins10:07:41

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.


that's a nice side effect


or design effect ;)