Frappe and ERPNext Germany: conflicting Tenacity versions?

The documented version conflict

The original report names Frappe 16.52.0 and a specific ERPNext Germany revision. Q1 Published Frappe source requires tenacity~=9.1.2, while the referenced Germany commit requires tenacity~=8.2.3. Q2 Q3 Under Python's compatible-release rules, these ranges do not overlap. Q5 That is a verifiable conflict for these revisions, not a statement about every later release.

Editing a local requirement may satisfy an installer without demonstrating that the applications behave correctly with the changed library.

Establish the actual package environment

1. Identify the environment precisely. Record Python, Frappe, ERPNext and Germany versions, including Git revisions. Inspect the affected Bench virtual environment rather than a globally installed Python interpreter.
2. Read actual dependency declarations. Compare installed project files with the referenced releases. A branch label such as version-16 is less precise than the commit actually deployed.
3. Check package consistency. In the appropriate Python context, run python -m pip check and preserve the output. pip documents this as checking compatible installed dependencies. Q4 It is a package-consistency check, not a complete application test.
4. Find a supported combination. Check whether a maintainer release resolves the conflict and which Frappe and ERPNext versions it supports. Build that combination first in a separate environment with traceable revisions.
5. Exercise affected behaviour. If an agreed patch is required, test the paths actually using Tenacity, including retry and error handling. Simulate external responses in tests; successfully importing the library is insufficient.

Document a reproducible resolution

Record the compatible combination and the reason for any exception. Using --no-deps, alternately forcing package versions or making undocumented changes inside installed packages does not establish application compatibility. A later normal build should reproduce the same valid state.

Before replacing a working deployment, compare the clean environment's package check and relevant application tests. Keep a coherent deployment recovery plan rather than relying on a single manually installed library version as the rollback strategy.

Frequently asked questions

Can I simply choose the higher version?

Only if the applications support that combination or it has been deliberately qualified. A higher version number alone does not demonstrate compatibility.

What information is useful for assistance?

Provide application versions with commits, Python interpreter path, relevant dependency declarations and pip check output. Customer records and production credentials are unnecessary for diagnosing this package conflict.

Help with this case

We can help isolate the affected process and prepare a controlled next step. Discuss case A0541 with KAN KAI WORKS.