I just ran into a small issue with org.clojure/tools.namespace, where when used in a deps.edn project would over-zealously by default load namespaces found in ~/.gitlibs. Presumably because prior to tools.deps it was assumed deps found on the filesystem were most likely to be source code in your project and suitable for loading. Would it make sense for tns to now by default ignore any paths found in ~/.gitlibs?

Incidentally this is easily fixed by explicitly setting tnsrepl/set-refresh-dirs, but it did cause a colleague to get a very misleading stacktrace about a missing class from a namespace that his project wasn’t explicitly requiring.

I should add that they likely weren’t even fully aware they were using tns, because they were using integrant.repl/reset (which uses it)

Cognitect’s test-runner seems to be accumulating issues and PRs without getting any feedback from Cognitect. Is it just considered “done” or just very low priority right now I wonder? I was thinking it would be really nice to have a -X entry point so that folks could leverage :exec-args and, in particular, their ability to merge across aliases so you could specify generic options via your :test alias (or :runner alias, in my case) and then specific options in other aliases. This would clean up a bit of boilerplate in our monorepo scenario where subprojects all have aliases but we still need to specify --dir via the command-line (since :main-opts don’t merge — just last-one-wins).

Luckily the test function in cognitect.test-runner is public so writing a tiny :exec-fn wrapper outside the runner is easy to do for now.

Just waiting for a cycle of attention

I’ll write the wrapper in our codebase for now and maybe submit a PR if/when test-runner gets an attention cycle.

Go for it!

The test runner is working well for me

@seancorfield I'd love to see an example invocation that is "better" with -X than with the -main function

We have a test alias for each subproject that brings in the test code and dependencies for that subproject. Via -X we can specify :exec-args {:dir #{"subproject/test"}} which will merge with our :runner alias which already has :exec-fn and the default :exec-args.

With -M, :main-opts do not merge so we either have to repeat the whole :main-opts for every subproject -test alias with just -d changed, or we have to specify -d on the command-line.

so now you have to write another alias for every -d change?

Before:

$ clojure -M:defaults:subproj:subproj-test:test:runner -d subproj/test

$ clojure -X:defaults:subproj:subproj-test:test:runner

@seancorfield Do you store these long invocations in some separate bash script or Makefile? Or do you remember them from the top of your head?

I'm currently considering a task runner which is supposed to solve this problem (of not having to remember these things)

This is why I am curious about these use cases

We have a build shell script that turns build test subproj into the above command. But now that we have a primary deps.edn file at the top of our monorepo, it’s easy enough to run most things with the CLI directly (for single command invocation).

The build script supports multiple commands so we could say build tests subproj1 subproj2 and it runs two clojure commands.

The example after -X is still pretty long, too long for me to remember without a bash history probably

We’re not going to invest more work in pipelining this stuff until we’ve seen tools.build released.

I’m anticipating being able to replace our build shell script with a tools.build invocation 🤞:skin-tone-2: 😸

I don't know what tools.build is, nor spec2 ;)

But I hope they come out soon ;) 🔮

Based on what Alex has said publicly about tools.build, I would expect it to include “task runner” functionality (and some “standard” tasks). ISTR he’s already mentioned that it will add Java compilation as a task?