https://github.com/polyfy/polylith/pull/517 -- I updated the Clojure version to 1.12.0 everywhere except the CircleCI images (CircleCI has nothing newer than 1.11.1! π ) and updated the sizes (in several tests) and everything passed locally. Given that CircleCI is so far behind, maybe Polylith should switch to GitHub Actions at this point? (I'll create an issue)
If you want to continue using CircleCI, you could consider using a different docker image. Cljdoc, for example, now uses the https://github.com/cljdoc/cljdoc/blob/5049108ba56f887c9e72096f774f309cf2dc73a7/.circleci/config.yml#L5, which is kept up to date. https://hub.docker.com/_/clojure/ (states it is "official" - which implies official Clojure, but clojure core team is not involved). Support available in #docker
Yup, that's what I suggested in https://github.com/polyfy/polylith/issues/518
https://github.com/polyfy/polylith/pull/519 -- this is a trivial update to ignore Calva's new REPL window (the old one was already ignored and I left that in place)
I found a situation with Polylith that is quite hard to debug when you run into it the first time.
Let's say you accidentally saved a syntax error like {:a} in a test namespace. This will give you an error message like Wrong number of args (0) passed to quote (and a not so useful stacktrace) because the extraction process of the test namespace fails due to the syntax error. Now that I know what's going on, I know that I have to look out for warnings at the top of the output like
Couldn't read file '/Users/jeroen/Projects/my-project/components/libs/src/my-project/libs/interface.clj', row: 119, column: 5. Message: The map literal starting with :a contains 1 form(s). Map literals must contain an even number of forms.
But because there are many lines between this warning and the eventual stacktrace dump it is hard to find the cause for this problem as the stacktrace dump doesn't tell you anything. The warning at the top will be the only way to debug this (except for cloning polylith locally and putting many println's π)
Of course the stacktrace dump could be improved (like earlier validation on empty namespaces), but the easiest solution maybe would be to have an option to fail fast on syntax errors? Anyone else ran into this error?@dingelsz3 ok now trying https://github.com/seancorfield/polylith-external-test-runner and it seems to make a big difference in helpful error messages
Thanks for the follow up. Iβll have to give it a try.
Just found that you can https://cljdoc.org/d/polylith/clj-poly/0.2.21/doc/reference/commands#test:~:text=with%3ACONFIG%20%20%20%20%20%20%20Merges,edn%20as%20example. the two runners as well. https://github.com/polyfy/polylith/blob/master/examples/test-runners/workspace.edn#L28C2-L32C111
And you can run multiple test runners at the same time π The latest external test runner version can also run both clojure.test (and Expectations) tests and LazyTest tests.
I had the exact same experience the other day. For me, itβs also hard to tell what component this is coming from. One can look at the list of components at the top of the test output, then see which components sucessfully ran and then see what component is next to help speed up the process of finding the bug but this is not ideal. I figured using a different test runner would help but havenβt had a chance to try that out yet.
This is why I advocate always eval'ing every piece of code you change via your editor while you are making changes. You'd catch this "immediately".
You are definitely right. Also if I would always commit in a disciplined way I would quickly find it too. My point is that polylith has this info and is already reporting it as a warning, but it is easy to miss. Maybe we can improve that more. I'll make an issue tomorrow and if there is consensus I'll try a PR. Like @zrothenberg1 I didn't try a custom runner yet and not sure if that prevents the issue