if missing workspace.toml, refer to pyproject.toml

[GH-maggio]

Description

Merged workspace.toml into pyproject.toml

Motivation and Context

Reduces number of configuration files, ref: Arbitrary tool configuration: the [tool] table

How Has This Been Tested?

Locally tested via pytest test

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• I have read the code of conduct.
• I have read the contributing guide.
• I have updated the documentation accordingly (if applicable).*

*If approved by the project maintainer, I will update the documentation.

[DavidVujic]

Thank you for this Pull Request @GH-maggio! ⭐

I'll have a look at this later today (at latest during the weekend).

[DavidVujic]

I have only had a quick look so far, and appreciate the effort and the good idea about having the tool-specific things in the pyproject.toml. ⭐

I added the workspace.toml feature before, to be able to determine where the workspace root is located. When using poetry, you could run poetry poly info from a subdirectory. It might be in a project directory where there is a project-specific pyproject.toml file already.

As an alternative that I can come up with from the top of my head, is to locate a pyproject.toml (instead of the workspace.toml), traverse the dictionaries as today, open each pyproject and look for a top-level config in there. That would work, I think!

I wouldn't want to overwrite any existing pyproject.toml file (created by poetry, hatch, pdm or rye already) when running "create workspace".

Maybe we should allow both alternatives: the workspace config in a workspace.toml or in a pyproject.toml. What do you think about that? I know some teams wanting their pyproject.tomls short and simple and without any extras, others want all the config in there. 😄

If so, the poly create workspace could do things as-is, but the dev team would be able to move that from it and put it in the pyproject.toml file instead if they like.

[GH-maggio]

If so, the poly create workspace could do things as-is, but the dev team would be able to move that from it and put it in the pyproject.toml file instead if they like.

I think that is the best course, also to avoid breaking the current behavior. So the poly-cli tool should default to creating/locating/reading from workspace.toml; if it is missing the behavior to fallback to reading/locating the root pyproject.toml.

I'll refactor this PR to reflex this behavior.

[sonarqubecloud]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

[DavidVujic]

Great work! ⭐

I'll merge this and will publish a new version shortly. Huge thank you for making this improvement @GH-maggio 👏 👏 👏

[DavidVujic]

I have published new versions of the Poetry plugin and the CLI!

Also just updated the docs: https://davidvujic.github.io/python-polylith-docs/configuration/
(and the other sections where "workspace.toml" is mentioned).