python-poetry
poetry init should support generating classic [tool.poetry] layout by default (or via flag) | works well on Windows it causes trouble in Linux and MacOS.
Description
Currently, poetry init adopts the PEP 621-style [project] section with inline tables for authors and dependencies by default. While this is standard‑compliant, many teams still prefer the classic [tool.poetry] layout with explicit packages = [...] and separate dependency sections—particularly for Django-style applications with multiple modules. Unfortunately, there’s no flag or config option to switch this behavior in Poetry 2.x, requiring manual edits post‑init on Linux, macOS, and Windows.
Though the default format works well on Windows it causes trouble in Linux and MacOS.
Proposal Enhance poetry init (and optionally poetry new) by supporting a new flag or configuration, such as
- --tool-poetry: generate [tool.poetry]-style metadata
- --package-mode: align metadata generation with package mode expectations
- Or add a .poetryrc config option (e.g., init.use_tool_poetry = true)
With one of these additions, users can opt into classic layout that includes:
toml
[tool.poetry]
name = "my-app"
version = "0.1.0"
authors = ["Name <email>"]
packages = [{include = "Ai_literacy_bot"}, {include = "app"}]
[tool.poetry.dependencies]
django = ">=5.2.3,<6.0.0"
...
Workarounds
Workaround can be manually edit the default generated pyproject.toml file to opt into classic layout!
Poetry Installation Method
pipx
Operating System
Linux
Poetry Version
2.1.3
Poetry Configuration
cache-dir = "C:\\Users\\bhavy\\AppData\\Local\\pypoetry\\Cache"
data-dir = "C:\\Users\\bhavy\\AppData\\Roaming\\pypoetry"
installer.max-workers = null
installer.no-binary = null
installer.only-binary = null
installer.parallel = true
installer.re-resolve = true
keyring.enabled = true
python.installation-dir = "{data-dir}\\python" # C:\Users\bhavy\AppData\Roaming\pypoetry\python
requests.max-retries = 0
solver.lazy-wheel = true
system-git-client = false
virtualenvs.create = true
virtualenvs.in-project = null
virtualenvs.options.always-copy = false
virtualenvs.options.no-pip = false
virtualenvs.options.system-site-packages = false
virtualenvs.path = "{cache-dir}\\virtualenvs" # C:\Users\bhavy\AppData\Local\pypoetry\Cache\virtualenvs
virtualenvs.prompt = "{project_name}-py{python_version}"
virtualenvs.use-poetry-python = false
Python Sysconfig
sysconfig.log
Paste the output of 'python -m sysconfig', over this line.
Example pyproject.toml
[project]
name = "ai-literacy-bot"
version = "0.1.0"
description = ""
authors = [
{name = "Arshit Arora",email = "[email protected]"}
]
readme = "README.md"
requires-python = ">=3.11"
dependencies = [
"django (>=5.2.3,<6.0.0)",
"pydantic (>=2.11.7,<3.0.0)",
"google-generativeai (>=0.8.5,<0.9.0)",
"python-dotenv (>=1.1.1,<2.0.0)",
"pydantic-settings (>=2.10.1,<3.0.0)",
"gunicorn (>=23.0.0,<24.0.0)",
"colorlog (>=6.9.0,<7.0.0)",
"gradio (>=4.0.0,<5.0.0)",
"requests (>=2.31.0,<3.0.0)"
]
[build-system]
requires = ["poetry-core>=2.0.0,<3.0.0"]
build-backend = "poetry.core.masonry.api"
Poetry Runtime Logs
poetry-runtime.log
Paste the output of 'poetry -vvv <command>', over this line.
This sounds like a step backwards, you will likely need to make a stronger case than "some teams prefer".
causes trouble in Linux and MacOS
You didn't say what "trouble" you are seeing
We deprecated some of the fields in tool.poetry - read the docs or run poetry check to see which fields are deprecated - and we definitively do not want to generate a pyproject.toml with deprecated fields. Thus, it is either undeprecating them or only use the fields in the tool.poetry section that are not deprecated (e.g. dependencies).
Taking your example and only using fields which are not deprecated:
[project]
name = "my-app"
version = "0.1.0"
authors = [
{name = "Name", email = "email"},
]
dynamic = [ "dependencies" ]
[tool.poetry]
packages = [{include = "Ai_literacy_bot"}, {include = "app"}]
[tool.poetry.dependencies]
django = ">=5.2.3,<6.0.0"
If you are just interested in poetry-style dependencies that should be the way to go. If you have a good reason for other (deprecated) fields that is something we would have to understand better first before making a decision.
My take on this is that at some point we will remove the deprecated fields and support for old [tool.poetry] definitions, so I don't think we want to encourage users to keep to that.
That makes sense. If we eventually deprecate those fields and drop support for the old definitions, we can remove the flag at that point of time. Until that happens, keeping the flag could be a practical choice, it saves time for users who still rely on the old definitions for compatibility.