Yes, the 0.2.19-SNAPSHOT introduced a breaking change, so the Kaocha doesn't work right now. @U08BJGV6E is working on a fix, so that it will support both the old format and 0.2.19. This will probably be fixed this week I think. In the meantime (if you have converted your workspace) you should be able to have both the old :projects key in workspace.edn with your test configs and the project config.edn files (the tool can read both the old and the new format), as a work-around.

It seems we missed something about converting workspaces, I'll look into that as well 🙂

Thanks for the heads-up!

@U1G0HH87L have you documentation about that workspace vs config.edn change?

Yes, the new snapshot documentation is updated, e.g. the https://cljdoc.org/d/polylith/clj-poly/0.2.19-SNAPSHOT/doc/project doc.

I meant a doc about converting your workspace to the new format

You can see the changes https://cljdoc.org/d/polylith/clj-poly/0.2.19-SNAPSHOT/doc/versions. Keys have basically moved from project-to-... keys to each project.

perfect, thank you!

Can poly use a different file name than config.edn? We already have config.edn files in some of our project dirs...

I can make that configurable.

I think that might be a good idea. config.edn is a quite generic name, high risk of conflict. Normally you see those in subfolders (`.lsp/config.edn`, .clj-kondo/config.edn), then the risk of conflict is not there.

I'm not saying that they should be in subfolders for poly by the way, but having a way to change that (file) name seems like a good idea.

My original idea was to use project.edn , base.edn , and component.edn. Maybe we should use that naming pattern instead.

Then we probably don't have to support configuring the name of the config files.

Suggestion: use the same filename everywhere but make it poly specific. Config, project, component are too generic

Same file name: they wont appear in the same folder anyway

There are pros and cons for either. One difference (positive or negative depending on your taste) is that having the same file name causes there to be multiple files with the same name in your editor. Also with deps.edn, I have so many in my project. In practice due to good completion behavior of vscode this is not a problem for me.

If we make it configurable, then we can maybe leave it as it is.

@UGNFXV1FA can you try aece34ab40255fd40038abbff79433fdf7cd5759 of polylith-kaocha and let me know if it works?

Maybe I'm getting that wrong but https://github.com/imrekoszo/polylith-kaocha/commit/aece34ab40255fd40038abbff79433fdf7cd5759 gives "not found" for me?

https://github.com/imrekoszo/polylith-kaocha/commit/a38bd8b3d760d34aa402f58b3732839fb7b34951

Sorry, wrong commit sha

That seems to work. I do get tons of debug level logging, which I believe (but am not sure!) was disabled before using logback config. But that can very well be a problem on my end. Is that something that might be explained by your changes you think?

I haven't made changes to logging

No I was more thinking in terms of search paths / class paths or something.

It's probably us who's causing this, not you.

I did bump some deps but they are mostly just poly and kaocha so it could be on your side yes

Thanks for confirming it look okay

I'll do an official release later today hopefully

Putting another copy of logback.xml in my project's resources folder fixes the logging. This is a downside of poly really, that you get lots of duplication in deps.edn files and resources like that logback.xml and build.clj if you're not careful and clever about it.

Multiple build.clj files are somewhat surprising to me

That's probably us being not clever enough then 😅. It was a LONG time ago since we set this up, maybe things have changed since then. We have a build.clj symlink in each project folder. They all link to the same file, but that way we can do clojure -T:build uberjar ... in each project folder.

Sounds legit tho

So I assume you're going to make a new release of the kaocha wrapper/runner one of these days right? Then I'll remove the explicit sha again and wait for your release, we're not in a hurry.

I'll either tag this commit or add one on top really

Unless issues surface till then

I can confirm that a38bd8b works with 0.2.19-SNAPSHOT. I will have another look again tonight.

@UGNFXV1FA An alternative is to have a single build.clj file at the workspace root. This is how the polylith repo handles it.

@U1G0HH87L That's good to know, I'll try that, thanks!

Released as https://github.com/imrekoszo/polylith-kaocha/releases/tag/v0.8.4

We have a single build.clj file at work and build two dozen projects with it in our Polylith repo. Every project does have its own logging config file tho'...

And we have about 200 deps.edn files:grin:

🙂 I guess deps.edn is the new package.json 🙂

I guess I'm doing something wrong @U08BJGV6E. I have create the https://github.com/polyfy/polylith/tree/prepare-0219/examples/test-runners example project. When I execute clojure -M:poly test :all project:kaocha-override-global from the workspace root, it can't find the kaocha-wrapper. Maybe someone can have a look.

Projects tested with kaocha need a test dep on kaocha wrapper

Okay, will have a try.

https://github.com/imrekoszo/polylith-kaocha?tab=readme-ov-file#3-add-kaocha-wrapper-dep-to-affected-projects

Interesting. My external test runner can be added as part of the :poly dependency in the workspace deps.edn file...

Kaocha needs to be in-classloader

Now it works, thanks!

Because it replaces the clojure.test/run-tests part

Ah, right... whereas mine still leverages all the standard clojure.test stuff and only needs to add just its "main" ns source to the classpath in order to run the tests...

Yep

And the -wrapper around it understands how to initialize kaocha based on the instructions given by the poly-tool side plugin

The latest release https://cljdoc.org/d/polylith/clj-poly/0.2.19-SNAPSHOT/doc/readme release, supports setting the :config-filename, see an example https://github.com/polyfy/polylith/blob/a55d1754a0df4eb37d5c60b869838d9ee1b195c2/workspace.edn#L6 @UGNFXV1FA

Thanks for the heads-up @U1G0HH87L. I noticed that this was now also reverted and removed from the release right?

Yes, the configuration of projects and base is moved back to workspace.edn but the internal move of (mostly) project settings in the workspace structure is kept as it is.

So it should be safe to use "as is" except if you use another test runner than the default one!

is config in config.edn files still supported or did that get removed entirely?

(I updated p/k to config.edns when I caught up with the previous breaking change)

So it should be safe to use "as is" except if you use another test runner than the default one!So with kaocha we do need to change something?

config.edn files have been rolled back entirely, so for those who has migrated already, they (unfortunately) have to rollback those changes (delete all config.edn files and move the config back to workspace.edn.

I'll try to remember to do that when I have the time

@UGNFXV1FA it shouldn't affect consumers

of p-k

> they (unfortunately) have to rollback those changes This is when small commits in git are so useful 😉

Totally agree! Stop squashing those branches peops! :)