Nested brick support in *poly check* command

[Paulskit]

First of all, thank you for the great library! It really simplifies my workflows when building multiple libs from the same monorepo!

Description

When using nested component structures in a Polylith project, the poly check command fails to locate components even though the build process works correctly.

Project Structure

project/
├── components/
│   └── namespace/
│       └── aws/
│           ├── s3/
│           └── glue/
└── bases/
    └── namespace/
        └── cli/

Configuration

pyproject.toml:

[tool.polylith.bricks]
"../../bases/namespace/cli" = "namespace/cli"
"../../components/namespace/aws/s3" = "namespace/aws/s3"

Then I've got

from namespace.aws.s3 import my_s3_func

...
my_3_func()

Everything builds and works as expected, except poly check command, which throws
🤔 Cannot locate aws in cli

I believe the root cause of the behaviour is here:

The code checks for p.name which is s3 and p.parent.name is not a namespace, but a namespace/aws. Thus, the missing brick.

I'm not sure whether described behavior is expected, but it's really handy to organise things this way, so that you can include only a specific brick you're using, not the entire folder.
My expectation was it should work with poly check as well, since it works perfectly during the build and the resulting .whl executes with no issues at all.

[DavidVujic]

Hi @Paulskit,

I'm happy to hear that you like Polylith!

I think this is expected behavior because the added things should be on brick-level and Polylith considers aws as one brick. I would suggest that you either add the entire aws brick, or separate the sub-namespaces s3 and glue into their own bricks. If you want them visually grouped in the folder structure, you could name the bricks with a prefix, such as aws_s3.

[Paulskit]

I somewhat agree. In a way the project is structured, there are bricks, just top level components, no nesting, subbricks or similar concept. That all makes sense.
Usage wise, I’m 50:50. I was using poly check as a quick CI check “will it build and whether everything is in proper place”. Now, the build is actually working fine, whilst the command is failing. Well, not failing, but basically saying “it won’t work”. It’s not a false positive in a way it says it will, but it actually doesn’t, which would’ve been a shame. But it’s still can’t be used for that purpose.
I’m curious why build actually works fine. Is it polylith that handles these paths differently in the hook? Or it’s hatch that takes over the process and can handle those gracefully?

[DavidVujic]

When you build, it is the underlying package & dependency management tool that does the work (i.e. uv, poetry, hatch ...) and the Polylith tool is handing over the list of paths that are defined in the project. From a pure tech perspective, everything works!

The check command is to validate if any bricks are missing, and it also validates the expected Polylith structure. That's why the check command will report a failure. I think that if you would run the poly sync command, it would probably also add the missing bricks according to the expected structure.

The poly info command will show aws as a brick (and not the sub-namespaces).

[DavidVujic]

(moving this to the Q&A discussions section)