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

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: https://clojurians-log.clojureverse.org/leiningen/2020-01-30 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 am afraid there is no 1 answer

Taka a look on https://github.com/weavejester/integrant 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?

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"))

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

all seqs are potentially lazy

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

That's ace, thanks!

the important thing is that list is open-ended

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

jinx

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