If you export your workspace to a file and post it to me, then I can take a closer look. E.g., execute poly out:timo.edn from the workspace root, and send the file directly to me personally on Slack.

I would put the env-folder in the resources of the projects since they are related to the build process. Although I really don't like the idea of code changing between dev/test/CI/production etc...

do I understand right, that dev-aliases in bricks are disregarded when starting a dev-repl in the workspace? but test-aliases work?

What exact do you mean with "dev-aliases in bricks", do you have an example? The general advice is that you should not put dev related code within bricks, only under development.

right, makes sense... just wanted to know if they are somehow 'loaded' or just disregarded

All directories that are specified in a brick's deps.edn in :paths or as :local/root in :deps , will be added to the source context, e.g. :paths ["src" "src2" "resources"]. The same goes for the test context, but that lives in another place, e.g. :aliases {:test {:extra-paths ["test" "test2"]. tools.deps supports having more than one source or test directory, and that is also supported by the poly tool.

You can browse the paths that the tool picks up with the ws command, e.g.: poly ws get:bases:yobst-core:paths poly ws get:projects:yobst-core-service:paths If you add a brick as a dependency to a project, using :local/root, they will still be stored as paths here, and you can run those commands to verify that the tool does what you want. This is most easily done from a https://polylith.gitbook.io/poly/workflow/shell.

I dissolved these env-nses and made it part of the integrant-system.edn. it works like that and pretty happy so far with polylith.