Fork me on GitHub

Quick question: Any compelling reason to drop lein in favor of deps ?


I think the short answer is: If Lein is doing what you need it to, then maybe check out discussions like that one to see what the differences are, and see if anything interests you in investigating deps.edn further. If you don't see anything enticing, why switch?


Thanks, I’ll check it out!


I'd respond here but I've already responded at length in that ClojureVerse post 🙂


Nice observations about :pedantic? mode. I'm bit of a fan of :pedantic? however that might be Stockholm syndrome :) OTOH I'm not entirely sure if I'd like defaulting to recent versions in practice. I'd rather default to nothing if the algo has to decide anything at all that implies risks


When I used Leiningen, I also relied heavily on :pedantic? mode and I used :exclusions to sort everything out. Since I switched to CLI/`deps.edn`, I've never needed :exclusions since I know t.d.a. will use the version I specify explicitly, or it'll pick the latest version that anything requests. Simple. Predictable.


Picking latest may be straightforward and predictable but I (genuinely) wonder about its simplicity (I'm not anti deps or anything) From Miller's talks I vaguely recall that some dependency chains can be so intrincate that there's no perfect, automatable answer for "how to resolve?" e.g. latest may be deterministic but what if the result breaks your code in practice? (not unheard of)


Sure, and that happens with almost any project that pulls in the Jackson Java libs -- until you figure out the magic version of Jackson that doesn't break the oldest code that needs it and still works with the most recent code that needs it 🙂

👍 4

For a while clj-new had to have dependencies on Jackons directly, pinned to 2.7.5, to avoid conflicts with some old Leiningen templates.


Yeah I see thanks! i.e. latest may not be perfect but at least could kill the easiest 80% right


in my personal feelings lein do too much, developers made from it multi tool which shouldn’t be. They wrote extra plugins to compile third party code in other languages in project and do other weird things which should be done in CICD instead. project.clj is so often unnecessary complex, because developers can do things, so they do. deps.edn let me easy point to clojars / m2 / git repository / local directory when I develop modules. It is clean solution which do only what should do: compile clj(s) / REPL / and a few things around. “less is more” But this is my opinion


So in all new projects where I have power to choose, I choose deps.edn


is there a lein environment variable that species the .m2 directory location?


so something simillar to: BOOT_LOCAL_REPO


i think there was a recent discussion about this on #leiningen -- starting around here: extending on to the next day. iirc, the answer was that there wasn't currently.


Can't you specify <localRepository> in your ~/.m2/settings.xml file to override the default location? And you can use a system property to override that on a per-invocation basis?


I haven't tried it but...


Hmm, I guess not. I thought lein's Maven/Aether stuff would respect that 😞


A question about software architecture with Clojure: I’m always struggling to think about the best way to organize a new Clojure project. I want to create a new project that gonna have a login (user/pass, social login, etc) and two or three features so I can test it. What is the best way to organize it? I was looking into hexagonal architecture and Stuart Sierra’s Component framework but I’d like to see a practical example so I could understand it better. This project would start as a monolithic. How could I organize it so it’d be ease to split into other services in the future?


I hint an integration between business-facing architecture and Component here;cid=C03RZGPG3 As for implementation details (how to make the monolith enjoyable but also splittable) you may find inspiration from Sierra himself:


I am afraid there is no 1 answer


Taka a look on instead of Sierra component


(^this is my preference)


architecture is not constant, you can start from something and later split this into a few services


there is really no answer, start to experience this yourself. Do not by afraid about experimenting and changing architecture. Do not overcomplicate simple things and always care about simplicity and readability. In the past I was doing experiments like write some app and add some new crazy business conditions like “hide all id for users, use uuid instead” etc. So architecture has to be elastic for changes. After all I think the best way is too keep everything as simple and readable as you can for needs which you have NOW. Everything has cost. If you want to have great architecture which let you use whatever DB you want or any during testings you have to add complexity. So do this when you need this instead of before.


I see. I’m always thinking the best way to organize the project so when I have to change it I don’t have to make to much changes And with Clojure it appear to be more difficult (for me, I’m used with Java patterns) Thanks @kwladyka. I’ll take a look into Integrant and try to keep simple for now


Has anyone put together a Heroku buildback for using the clj command line tool rather than Leiningen?


Yep. I started with and removed everything Lein-related. Ended up with something that's just about 10% in size of what it was. But it also has some app-specific things that I didn't really want to extract, so cannot really share it.


Apart from Lein, there's also some junk that won't be needed - some Ruby code, Node.js detection, maybe something else. The point is, it's pretty easy to delete all this and end up with a proper clj buildpack.


Cool. Thanks. You described my plan B and it’s nice to know the process yields something that works. I’m not sure what I’m ultimately going to be doing for the front end, so I’ll probably keep the Node.js crap in there.


There's a separate Node.js buildpack. And that's what should be used. I don't really remember why the Node.js stuff was in the Clojure buildpack to begin with. Maybe some JS code was in there, or some Lein plugin.


Ah, nice to know. It’s been over five years since I thought deeply about Heroku buildpacks.


Tempted to forbid laziness (in a very specific context of course, for a good reason):

(when (-> v class #{LazySeq})
  (assert false "Parallel processing shouldn't return lazy computations"))
Any other class I should add to #{clojure.lang.LazySeq}?

Alex Miller (Clojure team)14:02:36

there are many other seqs that are lazy, that are not LazySeq

Alex Miller (Clojure team)14:02:22

all seqs are potentially lazy

Alex Miller (Clojure team)14:02:28

a non-exhaustive list off the top of my head: Range, LongRange, Cycle, Iterate, Repeat, IteratorSeq, Cons,

💯 4

ChunkedCons is another common one


That's ace, thanks!

Alex Miller (Clojure team)14:02:38

the important thing is that list is open-ended

Alex Miller (Clojure team)14:02:49

generically, that assertion seems incorrect to me - parallel processing often returns lazy results (pmap is one example)


A simpler approach (vs. my initial blacklisting idea) might be asserting that v is a vector? if it's sequential?. That way I don't bake clj internals in my code. --- pmap is lazy so it makes sense that fs passed to it can return lazy results my parallel processing thing is eager, so having lazy results means that I can be doing almost no work in parallel, and the real work in a later computation that forces the lazy computations


since the list is open-ended, you could check instead for vectors as input



🔒 4

don't know what the use-case is


seq? is another useful one.


Or just allowed realized lazy seqs anyway. Check that it has the right shape and is realized?


realized? would not be enough on a seq


and wouldn't work in a lot of cases