Clojurians Log v2

Are you thinking of overriding the config (e.g. bb --config deps.edn), or about a separate (new?) capability? Assuming that deps.edn is effectively the bb config, a thing that comes to mind as a con is potential bleedover with other keys (e.g. deps and paths), and potential drawbacks from that, e.g. latency for classpaths or needing to put any bb code in the same dir as 'project code'. And of course, as a really long shot, if :tasks ever becomes meaningful to deps itself, maybe that gets messy.

Ah, yes, the conflict of :deps and :paths is big "con".

another con is that deps used for bb.tasks aren't always those from top level deps.edn

I guess if it happens to be a project where you have full control and know there's no conflicts, the bb --config deps.edn approach could work in those limited situations. But not as a general solution. Makes sense. I only ask because jolt vendors Babashka in, and supports both bb.edn and deps.edn, it supports :tasks in deps.edn in the absence of bb.edn. Just made me curious about the tradeoffs. Thanks, both of you.

I was thinking about "as long as the tasks are simple...", but my experience has been that sometimes tasks grow and might occasionally need a dep or a script file, so the deps.edn approach could slightly back you into a corner in the future. Tbf, I have a habit of ignoring YAGNI, so I could just be being an overly-cautious Andy.

My rule of thumb is that when a task gets longer than 5 lines, move it to a .clj file

Really cool 🤩 I don't want to trigger yet another project 😅 But every time I see similar news here, I think, oh cool, that could bring us back the good old times, where I just have to upload a bunch of files to my FTP server and everything is online (no build step, etc.). But this time with a great programming language instead of PHP. I know someone worked on a PHP-like or CGI-like thing in combination with SCI. However, just out of curiosity, do you think something like:

(pg/with-conn [db ""] ...

If making a connection is fast enough then yes. This depends on pg itself mostly. Just try it :)

SQLite might also be good (see the other lib), could be faster

bb.ffi would also make it less likely that you need to build your own babashka version and fight with GraalVM just to include a new library that no one has adapted for GraalVM native image yet?

perhaps