Fork me on GitHub


👏 4

Wondering how many of us are using Clojure CLI tools / deps.edn for our projects. I have been experimenting for a while, but think I am ready to do start doing some new project with CLI tools rather than Leiningen.


been watching it... just ditched boot from our toolchain and switched our cljs build over to shadow-cljs. i think moving the lein stuff over to deps.edn might be next


what was boot not providing you that you needed?


@U052SB76M we were only using boot for cljs builds (with less, dev http server etc) , and the shadow-cljs boot integration didn't look great, so we dropped boot and went with gulp for driving shadow-cljs


turns out gulp is awesome - i'd love to be able to define gulp tasks in cljs with lumo or something


I think we could probably use the node interop stuff like when you do cljs serverless builds on top of the underlying framework


yeah, probably... gulp tasks are just vanilla fns quite like ring handlers, so we could probably use gulp as a lib from a lumo script


As newbie, I tried both, but fell in with the deps.edn crowd and loving it 🙂


Took inspiration from juxt/edge and sean corfield dot repo


most side-projects only use deps.edn now


feels so much lighter than lein somehow


and love that I can use local dirs and git repos as an alternative to maven


the local dirs is a big win imo


Being able to use code straight from any git repository and specific commit would hopefully kill off any idea people have about creating mono-repos

👍 4

Before you know it you're writing monorepos of tools to manage your monorepos.


The heat death of the universe jumps a lot closer every time someone creates a mono-repo


We should write a satire program that manages infinite nested stacks of monomonomono...monomonorepos. Selling point is that you can put all of GitHub in that repo, then put all of GitHub, bitbucket and GitLab beside each other another level up.


Although I don't think that snark would go down very well with many people 😅


It might not go down very well with certain JavaScript focused devs... it does seem to be they who love the mono-repo... I think everyone else would love it 🙂


I wonder where that stems from, I guess the culture of breaking every single thing into it's own independent module. left-pad, I'm looking at you.


Yes, and I wonder how many people remember that pain... of if they have just buried their pain... in more mono-repos :rolling_on_the_floor_laughing:😂


as a JS dev I rather have all the stuff in a monorepo :P


i'm not a JS dev, but give me a sweet sweet monorepo every time


I spent way too much time opening n+1 PRs on different repos for the same feature, then cascading releases in CI, merging a few more PRs, releasing a few more things, etc. And in the end, I missed at least one dependency.


different requirements I guess ¯\(ツ)


All of my work happens in one repo


all of mine too ;)


I guess you could have a single project and a few build targets, and that's the same thing, you just offload that work to a different tool


but most of the JS build tools deal with a single target, so you need to have things like lerna


you could also have multiple "main" files and a "makefile" for each


@jr0cket Why you hatin' on monorepos? We love our monorepo setup and CLI/`deps.edn` is perfect for that scenario.


We started with Leiningen back in 2011 at work, switched completely to Boot in 2015, and switched completely to CLI/`deps.edn` at the end of 2018. We use Cognitect's test runner, my version of depstar and a few other small tools, plus a dedicated dev subproject for REPL/REBL setup.


Some of the issues around mono-repos are well define as there is a long history of this approach


All the monorepos I have experienced over the years have been terrible to use. Maybe people are being more responsible in the way they are using them now, bit I have never had the pleasure to see this.


I figure that if those companies use monorepos for their huge codebases, then monorepos can't be all that bad 🙂


The arguments against monorepos have never come across as strong to me. I have made extensive research on the topic in order to justify the Edge design. Nothing was particularly convincing. Most of the points made are often true whether you use non-mono or mono repos.


@U09LZR36F is edge designed to contain multiple different projects? For example if my company builds 10 different Clojure projects from various areas of the business they will all be from the one Edge repository?


@jr0cket They can be. I think a monorepo should serve a purpose though. If there are hard social/technical boundaries in your company e.g. you'd never know they were using clojure, then there's reduced purpose in a monorepo. If it's overlapping teams, with overlapping communications, then the monorepo is more valuable.


At JUXT we tend to end up with an Edge repo per major client project.


Thanks for sharing. Yes a repo per major project makes sense, especially in a consultancy situation. That is not really the monorepo as I have experienced them though, as they have had all the major projects in there 🙂


we're a product company with one app - each component of that app gets a module in a monorepo - life is much easier than when we had a repo per component


There is definitely different levels of scale when people talk about monorepos. If you had 10 different apps in the one repository, that would make me cry and need a lot of hugs 🙂


monorepo per product is v different from company-wide monorepo


yes, I suspect the term has been used to mean different things in the discussion we have had. The wikipedia article does define a monorepo as more of a company wide repo, or major area of business in large enough corps. On that scale I have always found it difficult to get anything done and seen huge amounts of duplication, but I think that is as much the culture as the tooling.


I tend to hear it used as a per-project thing e.g. for microservices - each service in a separate repo or all services in a ‘monorepo’


Our monorepo has our OAuth2 server, our public API server, our Login server, and Billing apps and Chat apps and a few other bits and pieces. Essentially it's all our Clojure code. Our legacy CFML code lives in a separate repo (which had three apps, now only two).


it's also worth considering the company scale in that too. In smaller companies, I suspect a company-wide repo is fine, it will probably encourage code-sharing & common libs between you. In those situations it seems fine. Smaller is left intentionally ambiguous here, because I'm not sure where the threshold is. Eventually you would probably stabilize the common lib api and split it out into it's own repo & lifecycle. I definitely see monorepos as a bell-curve. Early days = monorepo, mid-size = multi-repo, max-size (google/twitter) = monorepo


a lot of teams/business areas at the old place had monorepos and … the experience was mixed


depends on your discipline within that repo on keeping things sensible and decoupled


I imagine this is the old peopleware curse: we blame technology, when the problems are sociological!


it's the same as microservices vs monoliths. It's mostly down to team discipline rather than some inherent advancement.


the most disciplined teams tend to deliver better software more often, regardless of context


seen that in big teams and small, big companies and small now


I love talking about Clojure in the morning...


Wait, you mean it's possible to spend time not talking about Clojure? Uh oh.

Wes Hall15:07:23

I am using CLI tools for basically everything now, and think it's great. Lein was starting to feel a bit too much like maven. I like the lightweight. I am not convinced that all of the -R vs -C vs -O vs -M stuff isn't a bit over designed and I end up just using -A for everything, but as a sweet little bootstrapper, it's pretty... well... sweet.


I keep meaning to move over to clj, but stop every time I create a new project as I don't have the time to learn it. Is there a 30 second -> 5 minute guide out there about moving from lein to clj?


I snuck it in almost accidentally one time when I needed a clojure scratchpad with dependencies. Put a deps.edn in a folder with {:deps {cheshire {:mvn/version "5.8.0"}}} to pull in cheshire and cider-jacked-in and everything seemed to work.


ah, now that is something I'm glad to hear (as part of it for me has been understanding if I'd need to do anything to CIDER)



👍 4

@wesley.hall I use -R vs -A when I need to pull in dependencies but not run code, for example with my aliases for REBL and a few other things. Also on CI, where I use clojure -R:bunch:of:aliases -Spath > /dev/null to bring in all the dependencies so they can be cached, and then in the "run" portion of the job I use -A and it adds all the (now cached) deps to the classpath and also runs tests etc.


@otfrom If you stick my deps.edn in your ~/.clojure folder, then creating a new CLI project is just clj -A:new app otfrom/my-new-project and running tests in that project is just clj -A:test:runner

👍 4
Wes Hall15:07:39

@seancorfield Fair point that. Useful for building things like docker style images where you want all the deps loaded in, ready to go, at build time. I hadn't really thought of that. Perhaps I should rethink it 🙂.


I don't use the difference very often, and it's pretty much with just -R, but it's a useful feature.


imo having -<letter> is a pita but it’s a minor complaint


I don’t want to have to type flags ideally for a command I type a lot


(I know, I know, unix cmds, git etc etc)


We started with Leiningen back in 2011 at work, switched completely to Boot in 2015, and switched completely to CLI/`deps.edn` at the end of 2018. We use Cognitect's test runner, my version of depstar and a few other small tools, plus a dedicated dev subproject for REPL/REBL setup.

Wes Hall16:07:47

@alex.lynham It wasn't so much about the -<letter> convention but the model of splitting profiles into parts where you can use different letters to include different parts of different configurations in different ways. It always struck me as quite a lot of cognitive load. When I create a profile, I don't really think about it as something I can just decide to, "include the dependencies but not the options or entry point", my fairly puny brain can't get past the simpler model where the profile is either fully switched on, or fully switched off, though @seancorfield's example of using -R to simply download deps without running anything maps in my brain quite nicely onto similar things in other tools, so that use-case does actually make sense to me.