Fork me on GitHub

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: 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


@U06V097TP This is awesome! I made a babashka fork here. The changes are fairly minimal.


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


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


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:


Okay, interesting. But it needs to work for Datomic cloud also. I just talked with @U2BDZ9JG3 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 @U04V70XH6 and @U064X3EF3

Alex Miller (Clojure team)16:02:19

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


Okay, good to know.


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

Alex Miller (Clojure team)18:02:00

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 🙂

Alex Miller (Clojure team)19:02:49

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`
< vendor_path=/var/www/worldsingles/build/clojure
<   exec rlwrap -r -q '\"' -b "(){}[],^%#@\";:'" ${vendor_path}/bin/clojure "$@"
>   exec rlwrap -r -q '\"' -b "(){}[],^%#@\";:'" clojure "$@"

Sun Feb 07 11:17:40
(! 857)-> diff clojure/bin/clojure `which clojure`
< vendor_path=/var/www/worldsingles/build/clojure
< install_dir=${vendor_path}
> install_dir=/usr/local/Cellar/[email protected]/
That's the sum total of our changes (compared to the brew install'd version).


One more question to @U064X3EF3. Are you going to keep the support for absolute paths in :paths and :extra-paths? That could be a way out for us, to generate the deps.edn files for our projects, and instead of having relative paths, e.g. "../../components/command/src" as today, we could generate the paths, e.g. "/Users/tengstrand/source/polylith/components/command/src". We have tested this and it solves the issue we have for Datomic Cloud.


@U1G0HH87L And those generated files would be excluded from version control I assume? (we've had to do a similar thing)


It does make things a bit of a pain that you can't just check code out and run it -- the deps.edn files have to be generated first, so just using clojure/`clj` isn't enough.

Alex Miller (Clojure team)02:02:40

@U1G0HH87L we are planning to disallow paths and extra-paths outside the project root. I expect to add a warning for this soon and eventually it will be an error

Alex Miller (Clojure team)02:02:49

I think you’re going to have different but related problems with ions - this ever having worked with ions is more accident than intent. Ions rely on using shas as a way to differentiate versions. I don’t work on that stuff and defer to the Datomic team on the details.


Yeah, if something is outside the project, it should be a :local/root dep not a :paths thing.


Okay, then I know.