Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better support for nested repos or linked repos #305

Open
plexus opened this issue Aug 27, 2022 · 2 comments
Open

Better support for nested repos or linked repos #305

plexus opened this issue Aug 27, 2022 · 2 comments
Labels
improvement Incremental improvement of an existing feature

Comments

@plexus
Copy link
Member

plexus commented Aug 27, 2022

It is not uncommon for folks to have a single repo which contains multiple clojure "modules" or "packages" in subdirectories, each with their own deps.edn and tests.edn. Or to be working on multiple related projects at once by using :local/root in deps.edn.

Kaocha (in particular kaocha.runner and kaocha.repl) don't have a good story here, because they will only look for a tests.edn in the project's current working directory. You can point them to a different config file, but the (relative) paths provided in the tests.edn won't resolve to the intended paths.

Not sure yet how to best approach this, just leaving this here to be picked up and considered in the next development cycle.

I think the main mechanism that's needed is the ability to take multiple [test-config root-dir-path] pairs, and merge them into a single config, where source and tests paths have been adjusted accordingly.

@imrekoszo
Copy link
Contributor

imrekoszo commented Aug 29, 2022

Polylith is somewhat of a special animal in this sense. It provides the command line poly test which does a lot of things like detecting changes since the last stable build and creating classloaders for projects under test before running tests in said test loaders. This is necessary because a) not all of a poly workspace's submodules expose "complete" deps.edn files (as in they don't name all their required dependencies) b) poly will in most cases want to run not only tests defined in a project but from all internal modules referenced by that project.

I created polylith-kaocha to serve as an interface between the two:

  1. let poly do its work up to assembling a classloader and gathering source and test paths
  2. using this information configure an in-process kaocha invocation
  3. let kaocha do its test discorvery/running magic using all its plugins using the above config (via copying some of the logic from kaocha's cli

Because both poly and kaocha do a lot of special stuff I thought it's best to just let both do those and only connect them.

@alysbrooks
Copy link
Member

We have at least one Lambda Island project set up this way, plus it comes up with client projects, so I think this is a worthwhile issue to consider working on in the near future.

@alysbrooks alysbrooks added the improvement Incremental improvement of an existing feature label Jul 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement Incremental improvement of an existing feature
Projects
Status: 🙈Out of Scope
Development

No branches or pull requests

3 participants