Question about tool.poetry.version and PEP 621 for plugin development

[mtkennerly]

Hi! I maintain a plugin for dynamic versioning. It temporarily modifies pyproject.toml while Poetry is running and then cleans up after itself. For Poetry 2.0.0 and PEP 621, that means (ignoring some other details to keep the discussion simple) it needs to first remove tool.poetry.version and set project.version, then remove project.version and restore the original tool.poetry.version. The plugin could leave tool.poetry.version alone and just add/remove project.version, but that produces a warning from poetry check:

Warning: [project.version] and [tool.poetry.version] are both set. The latter will be ignored.
If you want to set the version dynamically via `poetry build --local-version` or you are using a plugin, which sets the version dynamically, you should define the version in [tool.poetry] and add 'version' to [project.dynamic].

However, when the plugin restores tool.poetry.version, tomlkit doesn't necessarily put it in the same place, which causes some friction for users (mtkennerly/poetry-dynamic-versioning#203). That in and of itself isn't a Poetry issue, but I'm wondering about why tool.poetry.version is required here and if making it optional would allow plugins to avoid the formatting issue to begin with. Would it be possible for Poetry to make tool.poetry.version optional when project is being used and project.dynamic contains "version"? In that case, the plugin wouldn't need to remove tool.poetry.version in the first place, and there wouldn't be any formatting issue when cleaning up the changes. Or how about silencing the warning when project.dynamic is set appropriately?

I'm not sure if this is an X/Y problem. If there's a different solution or expected way for plugins to handle this, please let me know.

(You might suggest simply reverting the entire file for clean-up instead of restoring specific data, but that won't work if Poetry itself or some other plugin also needs to retain modifications to pyproject.toml during the same command. Therefore, the plugin tries to selectively revert only its own changes.)

[radoering]

it needs to first remove tool.poetry.version and set project.version, then remove project.version and restore the original tool.poetry.version

Is it possible to leave project.version alone and just set and restore tool.poetry.version?

why tool.poetry.version is required here

Because otherwise Poetry will fail (without a plugin).

Would it be possible for Poetry to make tool.poetry.version optional when project is being used and project.dynamic contains "version"?

Unfortunately, that would be a broken config (without a plugin).

Or how about silencing the warning when project.dynamic is set appropriately?

Having version in project.dynamic and defining project.version is not allowed according to the standard if I do not miss anything.

[mtkennerly]

Is it possible to leave project.version alone and just set and restore tool.poetry.version?

I suppose that's possible, although then we'd be losing some of the benefits of PEP 621 for consumers of the build artifacts. For what it's worth, the plugin does stick to tool.poetry.version when it detects that a project is using Poetry 1's metadata, but it now tries to use project.version instead when it detects that a project is using the new fields supported by Poetry 2.

Unfortunately, that would be a broken config (without a plugin).

That's fair. I was hoping that the presence of project.dynamic = ["version"] would be a strong enough implication that the user is expecting a plugin to provide it, but I can understand that you'd prefer the config to always be self-sufficient even in the absence of an expected plugin.

Having version in project.dynamic and defining project.version is not allowed according to the standard if I do not miss anything.

The plugin also removes "version" from project.dynamic and then re-adds it when it's done. But you're right, then it would be too late for poetry check to know that project.dynamic had been set initially.

[radoering]

@mtkennerly Unrelated, but I thought you may want to check if poetry-dynamic-versioning is compatible with #10059.