i think the main thing to consider is that repls can take lots of arguments. aliases, main opts, etc. socket repl config, env variables before the command, etc. For people using nrepl, they have nrepl options and middleware to dynamically add it. For these reasons, I usually find that being unable to modify how a repl is started very frustrating. And the more layers of tooling involved, the more documentation you have to read. You need to understand how tool X preserves information to pass through tool Y so that the repl is started as clojure -A:dev . To me, clojure repls are so simple to start that I don’t usually see benefit from other tools between me and the repl.

Got it. However one can parameterize clojure aliases e.g. ALIASES=:dev:test:cider make repl . (Granted, that's a layer of indirection, but please assume there's a good reason to do this whole thing) Most of all, I'd be interested in a strong technical reason why running an interactive progam through Make would be problematic.

yeah. i do that with clj -M:"$ALIASES". I just don’t see what make would give me. and i have to know which env vars it expects and propagates. I don’t know anything about how make interacts with long running interactive processes. I see the one point about std in being randomly allocated to one of the threads which seems interesting. No idea otherwise

That's when using make -j (parallel execution), personally I've never even used that

i’ve seen that as almost always used when making projects. no reason to leave idle threads when building large projects

Yeah, that's fair. Most Makefiles I've seen in Clojure contexts are concerned with standardizing usage patterns - there's rarely much to be 'built'.

I've worked a lot with developers who are not using Clojure regularly and make is a simple enough tool to create a consistent command line UI across a wide range of languages and tooling. A Makefile with standard task was actually required in my previous commercial role. A project wouldnt be deployed to test or production without those make tasks. I like the convenience of make repl , make test-watch , make docker-build, etc so I dont have to remember all the commands and aliases I crafted for the specifics of the current project (especially all the docker stuff) The Makefile also provides a concise way to document common commands. The makefile can then be used as a reference for commands that can be used outside of make (also using the Shell history to minimise typing once the commands are used). Of course commands could be put in a well organised readme I've also never knowingly used the multiple jobs approach with make, especially for Clojure (although I assume they are more common building larger C/C++ code bases, perhaps make for Emacs uses multiple jobs). I didnt see any other reasons to avoid make for interactive commands offered in the Stack Overflow discussion. So in summary, I dont see any problems using make to start a repl. If you find make valuable, then use it. Providing make tasks doesnt prevent anyone from using (or modifying) the underlying commands if they prefer. I also include a Makefile with standard tasks in projects created with https://github.com/practicalli/project-templates

Thanks much! That's reassuring if you've used make repl substantially.

fwiw here's an example of something I do quite a bit:

LEIN := clean compile deploy install jar \
    release repl retest run test uberjar

$(LEIN):
        lein $@

Those lines would just be a part of my Makefiles which typically do much more. This technique can obviously work with any kind of CLI tooling that has subcommands that you want to expose as make targets. I use Makefiles extensively and even though I'm pretty new to Clojure they have worked out well there.

Thanks!

Also probably better to write it as

$(LEIN)::
        lein $@

test::
        another-test-command

PS. Here's a shell trick that often works for me when a process has lost its tty stdio for some reason; like being call from a process whose stdio is already being piped or redirected elsewhere:

lein repl < /dev/tty &> /dev/tty

echo | (lein repl < /dev/tty &> /dev/tty) > /dev/null

echo | (lein repl) > /dev/null
echo | (lein repl)
(lein repl) > /dev/null

but this isn't necessary for running shell commands in make (at least GNU make)

Thanks, I've saved it :)

For reference, this is the basic approach I take with a Makefile https://practical.li/engineering-playbook/build-tool/make/ There is also a great tutorial at https://makefiletutorial.com/

If you'll allow a small tangent in this thread, the arguments around using Makefiles as an easy-to-expect "least common denominator" of CLI tooling, reminds me of the https://testanything.org/ for trying to standardize test outputs across languages. I see parallels to both their pros of standardization and cons of inflexibility to language-specific tooling and granularity.

I use Makefiles and TAP testing often in at least half a dozen languages. Big fan of both.

As another tangent this is a pretty cool extension to GNU make that I whipped up a few years back http://makeplus.net/

I've gone pretty deep into make and bash. If anyone has issues with either ping me. I love that stuff.

I will freely admit, that my lizard brain quickly reaches for babashka if at all possible. :)

I made a library distribution system for bash last year called bpan. Mostly for reusing the bash libraries I've created over the years.

Well as I understand it but babashka is just a way to run bash commands generated from a Clojure syntax. One of the things that attracted me to Clojure was the way it interopped with existing technologies. So far my ambitions are to use it to get good ideas out to other languages, not to avoid other languages by doing everything from a clojure point of view.

You're right; but I specifically use it so I don't have to think about and improve my bash-fu (and can just pretend it's another Clojure program). 😅

But now we're really on a tangent of a tangent; apologies to others subscribed to this thread. :)

I don't know anyone who does more bash than me and I'm still learning every day so your approach makes sense to a lot of people I would think.

@U05476190 as long as we're this far off track https://github.com/bpan-org/test-tap-bash is my bash tap framework 😉