Poetry Manager throws Schema error on non-Poetry pyproject.toml

[EugeneBad]

How are you running Renovate?

Self-hosted Renovate

If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.

Gitlab

Please tell us more about your question or problem

Likely a bug: when Renovate encounters a pyproject.toml file that is not a Poetry-managed project (e.g., it's a PEP 621 project, or managed by another tool like pixi), the poetry manager attempts to parse it and throws a Schema error. Specifically:
"issues": {"tool": "Required"}

Which makes sense if the pyproject.toml file lacks a [tool.poetry] section -- since the renovate schema expects it: https://github.com/renovatebot/renovate/blob/main/lib/modules/manager/poetry/schema.ts#L344

Attempts to disable the manager in packageRules have failed:

{
  "packageRules": [
    {
      "matchManagers": ["poetry"],
      "enabled": false
    }
  ]
}

because renovate managers parse the repository before evaluating the packageRules.

An alternative would be to allow specific managers via the enabledManagers config. But as far as I can tell this is a somewhat global setting, there's no way to do this only for specific repositories.

Fix: An easier fix I can think of is an extra condition to just check whether the repository with the pyproject.toml file also has a poetry.lock file. If anyone can point me to, I can submit a fix. Thanks.

Logs (if relevant)

Logs

{"packageFile":"pyproject.toml","err":{"message":"Schema error","stack":"ZodError: Schema error\n    at Object.get error [as error] (/usr/local/renovate/node_modules/.pnpm/zod@3.24.2/node_modules/zod/lib/types.js:55:31)\n    at fromZodResult (/usr/local/renovate/lib/util/result.ts:60:67)\n    at Function.parse (/usr/local/renovate/lib/util/result.ts:566:12)\n    at Object.extractPackageFile (/usr/local/renovate/lib/modules/manager/poetry/extract.ts:20:36)\n    at extractPackageFile (/usr/local/renovate/lib/modules/manager/index.ts:75:9)\n    at getManagerPackageFiles (/usr/local/renovate/lib/workers/repository/extract/manager-files.ts:58:43)\n    at /usr/local/renovate/lib/workers/repository/extract/index.ts:57:28\n    at async Promise.all (index 4)\n    at extractAllDependencies (/usr/local/renovate/lib/workers/repository/extract/index.ts:54:26)\n    at extract (/usr/local/renovate/lib/workers/repository/process/extract-update.ts:160:28)\n    at extractDependencies (/usr/local/renovate/lib/workers/repository/process/index.ts:135:33)\n    at Object.renovateRepository (/usr/local/renovate/lib/workers/repository/index.ts:71:9)\n    at attributes.repository (/usr/local/renovate/lib/workers/global/index.ts:206:11)\n    at start (/usr/local/renovate/lib/workers/global/index.ts:191:7)\n    at /usr/local/renovate/lib/renovate.ts:19:22","issues":{"tool":"Required"}},"msg":"Poetry: error parsing pyproject.toml","time":"2025-06-04T18:30:06.285Z","v":0}

[rarkins]

I think we should avoid the user needing to configure things in such cases. A few possibilities:

1. Keeping it as-is but doing a simple pre-parsing check to confirm that it's a poetry variant of pyproject.yaml
2. Check for poetry.lock file. Is it always present for poetry?
3. Switch to using poetry.lock as the managerFilePatterns instead of pyproject.yaml

[EugeneBad]

I agree. Option 2 would be my preferred solution.
Yes, poetry always creates a poetry.lock file when installing dependencies. Docs: https://python-poetry.org/docs/basic-usage/#installing-dependencies

[rarkins]

Per the below, it's not mandatory to commit the poetry.lock, particularly for libraries.

So then the question is: if there's a pyproject.toml and no poetry.lock, can we treat it as vanilla pep621, or does poetry add poetry-specific syntax we need to care about into pyproject.toml?

[rarkins]

Adding some info from ChatGPT o4-mini-high about whether developers should always commit their poetry.lock:

In short, it depends on what kind of project you’re maintaining:

• For applications (apps, services, “end‐user” codebases):
  You should commit both pyproject.toml and poetry.lock.

  • Why?

    • pyproject.toml declares your desired dependency ranges (e.g. requests = "^2.28").
    • poetry.lock pins every subdependency (e.g. exactly which urllib3, which idna, etc.) so that anyone else (or your CI) who runs poetry install ends up with the same exact versions.
    • Committing poetry.lock ensures reproducible, deterministic installs across different machines/environments.

• For libraries (packages intended to be published on PyPI):
  It’s common to commit only pyproject.toml and not poetry.lock.

  • Why?

    • Library consumers (i.e. people who do pip install your‐library) will resolve their own dependency graph based on your declared ranges. They don’t need your lockfile; they need to pull in the latest compatible versions they choose.
    • Lockfiles for libraries can sometimes make sense if you want to test your package against a fully pinned set of dependencies in CI, but you generally don’t commit it into your VCS for end users.

---

When to commit poetry.lock

1. Executable projects (apps)

   • Example: a web service, CLI tool, or internal microservice.

   • You want everyone (and your deployment pipelines) to install the exact same subdependencies.

   • Commit both:

     ├── pyproject.toml
     └── poetry.lock
     

   • On change (e.g. poetry add flask), Poetry updates poetry.lock, and you commit that update so everyone else sees precisely which version of Flask (and all of its dependencies) to install.

2. Monorepos or multi‐service repos

   • Each service/app subfolder typically has its own lockfile.
   • Commit each service’s individual poetry.lock alongside its pyproject.toml to ensure reproducibility per‐service.

When you might skip (or remove) poetry.lock

1. Publishable libraries/packages

   • If you’re building a library meant for others to install via pip, you usually commit only pyproject.toml (because end users should resolve their own subdependency versions).
   • In that case, you might maintain a separate lockfile just for CI (e.g. to run your test suite against a consistent set of dependencies), but you don’t ship it in your “source distribution.”

2. Early‐stage prototypes or experiments

   • If you’re rapidly iterating and don’t care about locking (e.g. “I’m just trying out some random script”), you could skip committing poetry.lock. However, once you care about repeatable environments (CI, other devs, deployments), you’ll want to add it.

---

Common pitfalls if you omit poetry.lock on apps

• Two developers (or CI vs. local) might install slightly different subdependency versions and encounter obscure “works on my machine” bugs.
• You lose the ability to “pin” security patches in your lockfile; someone installing fresh six months later might pull in a version of a dependency that breaks compatibility.

Common pitfalls if you commit poetry.lock for a library

• Library users cannot easily “upgrade” into newer compatible versions of subdependencies—they’ll be stuck on exactly what you locked, unless they explicitly allow overrides.
• Publishing a locked set of transitive deps can lead to unnecessarily restricting your downstream users.

---

Recommendation

• If your repo is an application or service: ✅ Commit both pyproject.toml and poetry.lock.
• If your repo is a library meant for distribution: ✅ Commit only pyproject.toml (but keep a lockfile around for CI if you want stable tests).

That pattern is very common in the Python/Poetry ecosystem:

# Application repo
/pyproject.toml
/poetry.lock
/src/…

# Library repo
/pyproject.toml
# (no poetry.lock checked in; lock exists only locally or in CI)

[EugeneBad]

I think so, it'd be safest treat it as vanilla pep621.

A pyproject.toml file is mostly generic such that any python packaging manager can use it. In Poetry's case, the main distinguishing factors are the poetry.lock file or a [tool.poetry] header in the pyproject.toml file.

Without either conditions, renovate will just be guessing what manager the project is using.

[rarkins]

A vanilla pep621 manager would ignore tools.poetry. Is there nothing in there needing updating?

[EugeneBad]

From the pyproject.toml spec, it should: https://packaging.python.org/en/latest/specifications/pyproject-toml/#pyproject-toml-specification

The pyproject.toml file is written in TOML. Three tables are currently specified, namely [build-system], [project] and [tool]. Other tables are reserved for future use (tool-specific configuration should use the [tool] table).

[rarkins]

what should do what?

[EugeneBad]

pep621 manager should ignore tools.poetry

[rarkins]

Which would be a problem if it has entries needing updating

[EugeneBad]

Then the condition should parse first whether tools.poetry is present, such that renovate uses Poetry to update the entries. If not, use any other enabled/supported python managers.

The current behaviour/schema simply assumes the tools.poetry exists hence fails if it doesn't.

IMO the safest sure way is to still check for a poetry.lock file.

[rarkins]

It's not the safest way, it's actually a flawed way which would break a significant number of Poetry users.

[EugeneBad]

hhm well, the current behaviour is creating "false negatives" -- errors when it shouldn't. So yeah perhaps we have to pre-parse before applying the poetry schema.