Configuration
The Polylith Workspace is configured using a workspace.toml file at the root of the workspace.
A default configuration is created when running the poly create workspace command (see the commands section).
As an alternative, you can put the configuration in the top
pyproject.toml.
Example of a workspace configuration:
[tool.polylith]
namespace = "my_example_namespace"
[tool.polylith.structure]
theme = "loose"
[tool.polylith.tag.patterns]
stable = "stable-*"
release = "v[0-9]*"
[tool.polylith.resources]
brick_docs_enabled = false
[tool.polylith.test]
enabled = true
Tags
Check for changes since a tag. Configure the tag pattern.
The preferred way of defining tag patterns is:
By default, Polylith uses the -committerdate when fetching tags with the underlying git command.
The sorting might be incorrect when using annotated tags. To solve this, you can configure
the sorting.
Example, setting a different sorting option than the default:
Components and bases documentation
When brick_docs_enabeld = true, a README is added when creating a component or a base.
Testing
The create component and brick commands will also create corresponding unit tests when enabled = true in the test section of the workspace configuration.
Custom command output path
The poly info, poly deps and poly libs commands have support for a --save option.
By default, the command output will be saved to development/poly/<the command>.txt.
But you can configure it, if you want to store the output in a different location.
Example configuration:
Or, configure output location by command:
Project name alias
This is useful for Monorepos with many and/or very long project names. Using an alias for a project name can improve the visualization when running the poly commands (such as poly info). If there is an alias configured, it will be used in the tables instead of the project name.
Configure it in the root-level workspace.toml (or if you prefer the root-level pyproject.toml):
[tool.polylith.projects.alias]
my-api-project-name-with-a-long-name = "api"
my-kafka-handler-project-service = "kafka-handler"
Project groups
This is useful for teams using Domain Driven Design practices, such as bounded contexts, or have project types to separate individual projects in a Monorepo. In the Polylith context, the grouping of projects can now be used to filter out the poly info view by group(s).
This command will display the Workspace information, but will filter out the brick-project matrix in poly info to only show the projects in the selected group(s). You can add one or several groups to the command option.