Skip to content

[ADD] openupgradelib to 16/18/19 requirements - #83

Merged
yostashiro merged 1 commit into
masterfrom
add-openupgradelib
Aug 6, 2026
Merged

[ADD] openupgradelib to 16/18/19 requirements#83
yostashiro merged 1 commit into
masterfrom
add-openupgradelib

Conversation

@yostashiro

@yostashiro yostashiro commented Aug 6, 2026

Copy link
Copy Markdown
Member

Why

OCA migration scripts import openupgradelib (openupgrade.migrate, rename_fields, …) but almost never declare it in external_dependencies, so Odoo's dependency check cannot catch it. The failure surfaces as an ImportError part-way through a module upgrade.

Why the base rather than per-customer

A survey of the aggregated repos on the dev server found it imported by migration scripts in the large majority of active projects, spanning many modules — and declared in exactly one manifest, which sits under a .void/ directory.

It is upgrade machinery rather than any project's business logic, so it belongs next to git-aggregator in the base rather than being repeated in each per-project requirements file (and missed in one).

Notes

  • Unpinned, consistent with the rest of the file. Reproducibility is better served by immutable image tags than by a pin on this one package.
  • PyPI, not git. 3.13.6 was published at 2026-08-05T08:10:55 and OCA/openupgradelib master was last pushed at 2026-08-05T08:10:26 — 29 seconds apart, with five releases since June, so there is no staleness to route around.
  • Verified pip install openupgradelib succeeds on all three current bases (Python 3.10.20 / 3.10.20 / 3.12.13), resolving to 3.13.6.
  • Only master is touched. The legacy per-version branches (10.0, 15.0, 17.0) still carry the old single-Dockerfile layout and would each need the same change.

OCA migration scripts import openupgradelib (openupgrade.migrate,
rename_fields and friends) but almost never declare it in
external_dependencies, so Odoo's dependency check cannot catch it. The
failure surfaces as an ImportError part-way through a module upgrade.

A survey of the aggregated customer repos found it imported by migration
scripts in 9 of ~11 active projects (asx, axls, fal, hls12, ocj, rbkk,
rmm, sfa, thc) across ~16 modules; base_tier_validation alone spans three
customers. Exactly one manifest in the whole workspace declares it, and
that module sits under a .void/ directory.

It is upgrade machinery rather than any customer's business logic, so it
belongs in the base image next to git-aggregator rather than in each
per-customer requirements file.

Left unpinned, consistent with the rest of the file. Verified to install
on all three bases (Python 3.10.20 / 3.10.20 / 3.12.13).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@yostashiro
yostashiro merged commit 0552013 into master Aug 6, 2026
4 checks passed
@yostashiro
yostashiro deleted the add-openupgradelib branch August 6, 2026 15:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant