Plugin to migrate pyproject.toml from Poetry v1 to v2 (PEP-621 compliant)

[zyf722]

Hello to the community!

I've created a simple plugin for Poetry that helps you migrate your pyproject.toml files from Poetry v1 to v2 with PEP-621 standards.

With poetry migrate and an interactive CLI, you can easily migrate your pyproject.toml files from:

[tool.poetry]
name = "simple-project"
version = "1.2.3"
description = "Test project for poetry-plugin-migrate"
license = "MIT"
authors = [
    "Dev Guy <[email protected]>",
    "Test Guy <[email protected]>",
]
maintainers = [
    "Maintainer One <[email protected]>",
]
readme = "README.md"
homepage = "https://example.com/"
repository = "https://github.com/zyf722/poetry-plugin-migrate"
keywords = ["we", "just", "need", "some", "keywords"]
classifiers = [
    "Development Status :: 4 - Beta",
]

[tool.poetry.scripts]
main = "simple_project.__main__:main"

[[tool.poetry.source]]
name = "private"
url = "http://a.source.too.secret/simple"
priority = "supplemental"

[tool.poetry.dependencies]
python = "^3.9"
private-package = { version = "^1.0", source = "private" }
requests = "^2.0"
httpx = { version = "^0.23", python = "^3.9" }

[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"

to

[tool.poetry]
version = "1.2.3"
classifiers = [
    "Development Status :: 4 - Beta",
]
requires-poetry = '>=2.0.0,<3.0.0'

[[tool.poetry.source]]
name = "private"
url = "http://a.source.too.secret/simple"
priority = "supplemental"

[tool.poetry.dependencies]
python = "^3.9"
private-package = {  source = "private" }

[build-system]
requires = ['poetry-core (>=2.0.0,<3.0.0)']
build-backend = "poetry.core.masonry.api"

[project]
name = "simple-project"
description = "Test project for poetry-plugin-migrate"
license = "MIT"
keywords = ["we", "just", "need", "some", "keywords"]
dynamic = ["version", "classifiers"]
readme = "README.md"
authors = [{name = "Test Guy", email = "[email protected]"}, {name = "Dev Guy", email = "[email protected]"}]
maintainers = [{name = "Maintainer One", email = "[email protected]"}]
requires-python = '>=3.9,<4.0'
dependencies = ['private-package (>=1.0,<2.0)', 'requests (>=2.0,<3.0)', 'httpx (>=0.23,<0.24) ; python_version >= "3.9" and python_version < "4.0"']

[project.urls]
homepage = "https://example.com/"
repository = "https://github.com/zyf722/poetry-plugin-migrate"

[project.scripts]
main = "simple_project.__main__:main"

Feel free to check it out if you think it could be useful: https://github.com/zyf722/poetry-plugin-migrate

[finswimmer]

Look great @zyf722 👍

I would have some minor, optical suggestions:

• Instead of appending the project section to the file, I would prefer to have it at the top.
• Would be nice if there would be one dependency per line instead of one line for all.

[abn]

Great stuff. I agree with the above points.

Additional notes from me:

• default to version not being dynamic
• consider dependencies that "need" rich specification (eg: relative path dependencies)

[zyf722]

@finswimmer @abn

Thanks for your valuable suggestions! I'm really glad to get some feedback from Poetry maintainers.

• Would be nice if there would be one dependency per line instead of one line for all.

• default to version not being dynamic

I believe these two suggestions are straightforward to implement, and I'll include them in the next update.

• Instead of appending the project section to the file, I would prefer to have it at the top.

I fully agree with this. Might dig deeper into tomlkit later and see if custom sorting after migration is feasible.

• consider dependencies that "need" rich specification (eg: relative path dependencies)

If I understand this correctly, relative path dependencies are actually already covered in another more comprehensive example in the repo's README, along with examples for multiple constraints and extras.

However, they are just hypothetical cases for testing and not real-world scenarios. Since I don't have much experience with some advanced features of Poetry, I'm not sure if "expected" outcomes listed there are de-facto correct or match what users would expect. Any help in clarifying or validating those examples would be greatly appreciated.

[iTrooz]

It would be nice if there was an "auto" mode that didn't ask me questions, and directly translated the pyproject using the defaults

I'm also doubtful about some defaults

[tool.poetry.dependencies] found. `dependencies` will be added to [project.dynamic] if you want to keep it in [tool.poetry]. 
Keeps dependencies in [tool.poetry]? (yes/no)

Why would I want to do that ? The point of migrating is to use the standard, not keeping poetry-specific values, right ?

As a result, I just ended up re-initing the poetry project myself, because I was scared your tool would keep poetry-specific keys when not needed

[zyf722]

It would be nice if there was an "auto" mode that didn't ask me questions, and directly translated the pyproject using the defaults.

Actually, the -n or --no-interactive flag does exactly what you're asking for — it performs the migration using the default values without any prompts. Since this flag is shared across many of Poetry's built-in commands, I didn't include it in the documentation. I'll add a note about it in the README. Thanks for pointing that out!

I'm also doubtful about some defaults

[tool.poetry.dependencies] found. `dependencies` will be added to [project.dynamic] if you want to keep it in [tool.poetry]. 
Keeps dependencies in [tool.poetry]? (yes/no)

Why would I want to do that? The point of migrating is to use the standard, not keep poetry-specific values, right?

I completely understand your concern. Current behavior is designed to be more conservative, as I wanted to avoid breaking existing projects due to potential issues that this plugin itself might have. That said, I agree that the expected default behavior should be to move them to [project.dynamic], as that's the standard. This may change in the future.

As a result, I just ended up re-initing the poetry project myself, because I was worried your tool would keep poetry-specific keys when not needed.

Anyway, thanks again for your feedback. I'll work on improving the plugin moving forward :)

[iTrooz]

Whoops, I should have read the --help text better, sorry
thanks for your answer !