I am getting this error (when I change :top-namespace) and am having a little trouble figuring out how to debug it:
$ poly check
#error {
:cause nil
:via
[{:type java.lang.ClassCastException
:message nil}]
:trace
[]}
is there a verbose option I can use somewhere? I don't see it documentedI agree, that doesn't look very helpful. There is a :verbose flag that you can use, but it will unfortunately not help you in this case. Which version of the poly tool do you use?
poly version
poly 0.2.20 (2024-07-14)
which I just grabbed from nixpkgs unstable. I can try other versions too if you want me to investigate that. This was working at one point, but our repo has changed somewhat since then and I was perhaps using a different version of the CLI so either one could be the culpritThat version should be okay. When you change :top-namespace , do you also change the top namespace of all your bricks?
no, we are mid migration to polylith and I have been using poly check to see which namespaces+other changes need to be made. Oddly, poly check does not throw this error with the previous :top-namespace even though most of the component namespaces have the incorrect prefex. All poly commands seem to throw this error, not just poly check
Maybe you can try to locate the code that is problematic, by moving/renaming some of it, till the error disappears? Maybe start by copying the whole workspace, so that you have your little sandbox. When you know what triggers the error, you could create a small workspace that reproduces it, and create an issue, so that this could be fixed. If you have time and manage to reproduce it of course!
Cool I will definitely come back and make an issue or just say it was user error here once I nail it down. Thanks for taking a look!
You should make sure polylith is running with the jvm option that stops the jvm from omitting stack traces
-XX:-OmitStackTraceInFastThrow
Not sure what would need to be done to make the poly script set that
I believe the poly script respects JVM_OPTS so the following should work:
$ JVM_OPTS="-XX:-OmitStackTraceInFastThrow" poly check
...I haven't tried out FlowStorm yet, but it could maybe be used to track this down. https://www.youtube.com/watch?v=h8AFpZkAwPo is a recently demonstration of how to use it.
The JVM opt did not make the stacktrace appear, but as I was trying to create a minimal example, a stacktrace started to appear. https://github.com/polyfy/polylith/issues/504 gives a minimal reproduction for the bug that was causing a stacktrace.
Works for me. Which version of clojure do you use @mitchell_clojure? "clojure -version" gives 1.11.4.1474
[nix-shell:~/.../poly-test]$ clojure --version
Clojure CLI version 1.11.3.1463I will try to bump (may take a minute figuring out all the nix hoops to jump through) and see if that fixes it
I am still seeing the same error on
clojure --version
Clojure CLI version 1.11.4.1474
I updated the repo with a nix flake on the off chance that someone curious wants to reproduce and uses nixIt is not a showstopper for me, since I can likely downgrade and fix all my warnings, then upgrade back to the current version
I posted a comment on the ticket, it looks like a bricks dependencies are broken out into 3 bins and then each is sorted, but in 2 cases before being sorted the keyword :to-brick-id is effectively mapped over the deps, where as the last case "illegal deps" (whatever that means) the mapping doesn't happen, so the sorting is operating on the maps, where it fails
Ah thanks, probably better to centralize the discussion there now. I'll add a comment there to the above affect
I replied in the issue.
I have pushed a fix to master. Please try it out @mitchell_clojure.
yup! that fixes it both in my example repo and in the original repo. The empty error from the original post is also resolped. Thank you so much!
Happy to hear!