Clojurians Log v2

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)

I don’t understand - can you explain a repro in an ask.clojure question?

https://ask.clojure.org/index.php/10381/should-tools-namespace-repl-refresh-exclude-found-gitlibs

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?

Why would you ever not have a history?

That can happen when I switch systems yes, I have multiple laptops. But even then, fetching from history comes up with similar invocations and not always the one I'm looking for right away, unless I remember it more or less correctly. Hence, something like a task runner (something like make) could be nice

But also for making these invocations known to colleagues, contributors, etc, you don't want to depend on history

maybe; I am skeptical of lot of this additional tooling stuff. shells already support most of these things

everything goes in the history

support running all kinds of things, background jobs, etc

you don't write any docs for your colleagues how to invoke the tests like Sean showed? I would have a hard time figuring that out by only looking at deps.edn

it is already the case that I almost never type a command in full into my shell, I pull it out of history and maybe edit it

if you write docs then you already may as well just share the long command

"paste this into your shell, and it will run the tests"

if you do document this, you might as well make those docs executable somehow

yeah, that's usually how I've done it so far

I mean, I work with sean

Lucky you ;)

yeah, I mean, he does a lot of work on the tooling, so documentation wise it is way more likely to be written for me then by me :)