Decide Odoo tenant dependency lockfile policy

[cbusillo]

Objective

Decide whether owned Odoo addon dependencies should move to auditable uv lockfiles while preserving upstream and third-party requirement inputs.

Finish Line

The Odoo artifact dependency ownership policy is decided, documented, and either implemented for live tenants or explicitly deferred.

Current Status

State: Waiting. We aligned on a provisional two-layer direction, but implementation should wait until Launchplane backend/product artifact contracts stabilize enough to avoid baking the wrong boundary into odoo-devkit or odoo-docker.
Next action: Track Launchplane backend/product artifact contract work, especially cbusillo/launchplane#161, then return with read-only cross-repo recon before implementation.
Blocked by: Launchplane controller/product-environment artifact contract stability, plus final maintainer confirmation after that contract settles.
Last verified: 2026-05-03 after discussion in Code session.

Scope

• In: Tenant root uv lockfiles, owned addon dependency resolution, Dependabot auditability, artifact staging behavior, external requirement compatibility, final venv evidence.
• Out: Forcing lockfiles for pure addons with no Python dependencies or for third-party repos we do not control.

Acceptance Criteria

• Decide whether each live tenant repo owns one root uv.lock for owned addon dependencies.
• Define how odoo-devkit stages tenant root pyproject.toml/uv.lock into artifact builds.
• Preserve compatibility for external addons that only provide requirements files, while surfacing unlocked inputs in logs/evidence.
• Decide what Launchplane artifact manifests should record: lockfile hashes, final /venv freeze, and unlocked external inputs.
• Resolve OPW simple_zpl2 floating master risk by pinning, forking, publishing, vendoring, or replacing it.

Relationships

• Related tenant repos: cbusillo/odoo-tenant-cm, cbusillo/odoo-tenant-opw.
• Related addon/runtime repos: cbusillo/odoo-shared-addons, cbusillo/disable_odoo_online, cbusillo/odoo-docker.
• Related Launchplane controller work: cbusillo/launchplane#161.
• This plan should resume after Launchplane artifact/product-environment contracts are stable enough to define durable artifact evidence requirements.

Validation

• Generate tenant root lockfiles in a branch and run uv export --frozen.
• Build testing artifacts for CM and OPW and compare final /venv freeze output.
• Verify Launchplane still records the same image digest deployment flow.

Decisions

• Provisional: use a two-layer dependency model.
• Owned addons declare Python dependency intent close to the addon, preferably in addon-local pyproject.toml files.
• Tenant repos own the final deployable dependency resolution with one tenant-root uv.lock for the composed environment.
• Do not use an artifact-locks/ pattern for Launchplane-era flows; Launchplane should own artifact/controller evidence once its product-environment model is stable.
• Keep __manifest__.py as Odoo module metadata and validation signal, not the Python packaging source of truth.
• odoo-devkit likely owns dependency discovery/check/lock helper commands; odoo-docker should consume frozen inputs and install deterministically.
• Honor upstream Odoo, Odoo Enterprise, and third-party dependency declarations where we do not own them.
• Prefer one lockfile per owned deployable tenant boundary, not one central lockfile for all Odoo repos.

Open Questions

• Should artifact publish fail when owned addon dependency metadata exists but no tenant root lockfile covers it?
• Should external addon repos remain a compatibility lane indefinitely?
• For simple_zpl2, should OPW pin the current upstream commit, fork it, or replace/vendor the used surface?