Clojurians Log v2

If you like clj but miss the group dynamics that leiningen provided (with known names bound to actions), I whipped up a small joker script that provides support for common cases: https://gist.github.com/pyr/d5e17af9c572b681a57de52895437298. It allows doing klein {deps,run,repl,jar,uberjar,test} and supports inferring artifact versions from the command line. I'll see about turning it into a real repo, if there's any interest

It's missing a number of things (`new`, compile, javac, and support for submodules which we use extensively).

@pyr This is awesome! I made a babashka fork here. The changes are fairly minimal. https://gist.github.com/borkdude/c34e8e44eb5b4a6ca735bf8a86ff64fa

Would it be possible to support giving the name of the config file that should be used when executing a command (if it's something else than deps.edn) so that e.g. the 'poly' project config file could also live at the root along with 'deps.edn', and e.g. be named 'poly-deps.edn'. That would solve our problems we have in #polylith because then we could put all our project files at the root and refer to the source directories without using relative paths (all paths would then look like e.g. "components/mycomp/src"). I have started the work to support the new project structure where each component has its own deps.edn. I would like the different project deps.edn files to handle the components consistently, so that we either specify :paths and :extra-paths or :deps and :extra-deps for all projects. Mixing the two ways doesn't make sense, but if we could put all the project files at the workspace root, then we could more or less keep it as it is without referring to paths outside the projects.

It's not the official clojure deps runner, but my deps.clj project supports this with -Sdeps-file: https://github.com/borkdude/deps.clj

Okay, interesting. But it needs to work for Datomic cloud also. I just talked with @furkan3ayraktar and he said that we can't use :deps or :extra-deps for our single development environment, the deps.edn at the root "The reason we can’t use local/root approach in the root dep is that the REPL doesn’t work. You’ll loose the single dev environment and you can’t run tests from the REPL in that case.". So if we can't have all our project files at the root, we need to have a mix where we specify the paths for the development project and dependencies for all other projects. With the support that you have added, we could keep it consistent and simpler and it would make much more sense also, because there are no difference between the projects except that they contain a different set of building blocks. Maybe we could add an issue together.

There has been some discussion about a fourth deps.edn file (system, user, project, fourth) or n deps.edn files. cc @seancorfield and @alexmiller

I do not currently expect that is where we will end up

Okay, good to know.

really nice. I will play with the two and compare output sizes/times thanks!

@alexmiller is there any guidance you can offer at this point on what is likely to be the direction?

No, not trying to be coy. We are having ongoing discussions about combinations of features, problems, future directions, etc. It’s just hard to discuss without hours of context.

I look forward to several posts on Inside Clojure summarizing the possible solutions you discarded and why they wouldn't work 🙂

unlikely to ever get that. It’s just too hard to recreate multidimensional design discussions between a bunch of people over weeks/months.

🙂 Then I'll just look forward to whatever solution y'all eventually decide on and adjust our monorepo accordingly...

since tools.deps is a tool/lib, I can imagine some scripting on top of this can make any solution you want already. it's just not the official blessed bash script.

but deps.edn generation is always a way out as well

Yeah, that is also a direction I've considered -- but now that we are not using CLJ_CONFIG and we generate our "compound" deps.edn file, it's opened up the possibility to use clojure directly instead of having to use our build shell script... so I'm not thrilled about the idea of forcing developers back to a custom script 😐

Even with CLJ_CONFIG, we could use clojure directly: it was just rather verbose.

I now have custom clojure bash scripts in our mono-repo projects. These are also used by tools like clojure-lsp to calc the classpath

so instead of clojure -Sfoo you type ./clojure -Sfoo. Not custom as in a fork of the original, just something like CLJ_CONFIG=../base clojure -A:base. I guess what you had before

Yeah, we vendor clojure into our repo so we have a reliable, self-contained version, using a specific install path. But it's still "almost" identical to the official version. I'm trying not to fork it and diverge.

(! 856)-> diff clojure/bin/clj `which clj`
2c2
< vendor_path=/var/www/worldsingles/build/clojure
---
> 
4c4
<   exec rlwrap -r -q '\"' -b "(){}[],^%#@\";:'" ${vendor_path}/bin/clojure "$@"
---
>   exec rlwrap -r -q '\"' -b "(){}[],^%#@\";:'" clojure "$@"

Sun Feb 07 11:17:40
(sean)-(jobs:0)-(/Developer/workspace/wsmain/build)
(! 857)-> diff clojure/bin/clojure `which clojure`
2c2
< vendor_path=/var/www/worldsingles/build/clojure
---
> 
246c246
< install_dir=${vendor_path}
---
> install_dir=/usr/local/Cellar/clojure@1.10.2.774/1.10.2.774