polylith

eval-on-point 2024-08-08T19:15:00.411309Z

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 documented

tengstrand 2024-08-08T19:34:57.922979Z

I 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?

eval-on-point 2024-08-08T19:37:40.948639Z

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 culprit

tengstrand 2024-08-08T19:59:19.741079Z

That version should be okay. When you change :top-namespace , do you also change the top namespace of all your bricks?

eval-on-point 2024-08-08T20:02:20.479939Z

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

tengstrand 2024-08-08T20:14:28.785759Z

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!

eval-on-point 2024-08-08T20:15:23.630999Z

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!

👍 1
2024-08-09T01:38:20.949479Z

You should make sure polylith is running with the jvm option that stops the jvm from omitting stack traces

2024-08-09T01:38:58.947969Z

-XX:-OmitStackTraceInFastThrow

2024-08-09T01:39:16.953889Z

Not sure what would need to be done to make the poly script set that

seancorfield 2024-08-09T03:23:39.435939Z

I believe the poly script respects JVM_OPTS so the following should work:

$ JVM_OPTS="-XX:-OmitStackTraceInFastThrow" poly check
...

tengstrand 2024-08-09T07:03:37.609309Z

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.

eval-on-point 2024-08-09T14:36:00.736489Z

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.

tengstrand 2024-08-09T16:52:47.064909Z

Works for me. Which version of clojure do you use @mitchell_clojure? "clojure -version" gives 1.11.4.1474

eval-on-point 2024-08-09T16:55:08.559149Z

[nix-shell:~/.../poly-test]$ clojure --version
Clojure CLI version 1.11.3.1463

eval-on-point 2024-08-09T16:56:53.078829Z

I will try to bump (may take a minute figuring out all the nix hoops to jump through) and see if that fixes it

👍 1
eval-on-point 2024-08-09T17:28:52.717079Z

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 nix

eval-on-point 2024-08-09T17:31:07.150679Z

It is not a showstopper for me, since I can likely downgrade and fix all my warnings, then upgrade back to the current version

2024-08-09T17:31:54.206699Z

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

eval-on-point 2024-08-09T17:33:52.695349Z

Ah thanks, probably better to centralize the discussion there now. I'll add a comment there to the above affect

tengstrand 2024-08-09T18:18:51.041599Z

I replied in the issue.

tengstrand 2024-08-09T19:02:55.023019Z

I have pushed a fix to master. Please try it out @mitchell_clojure.

eval-on-point 2024-08-09T19:16:54.638099Z

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!

tengstrand 2024-08-09T19:30:12.728609Z

Happy to hear!