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: Completed on July 24, 2026.

All native dependency-policy implementation slices are complete:

• Launchplane schema-v2 dependency provenance: cbusillo/launchplane#1763.
• Frozen support/runtime and tenant-lock installation/evidence: cbusillo/odoo-docker#59 plus later base-chain hardening.
• Devkit workspace validation, immutable staging, manifest emission, layout parity, base-overlap preflight, and canonical package hash verification: Validate and stage tenant dependency workspaces for artifact publish #80 and follow-ups Close artifact dependency preflight parity gaps #87/Validate workspace globs against tracked addon layout #90/Preflight dependency locks against the exact base image #91/Test canonical package hash verification #92.
• CM tenant lock and first artifact pilot: cbusillo/odoo-tenant-cm#105.
• OPW tenant lock, immutable VCS inputs, and final artifact pilot: cbusillo/odoo-tenant-opw#101.

CM artifact artifact-cm-80f7e46a414b98d9 completed the Launchplane testing golden path under cbusillo/launchplane#1768. OPW artifact artifact-opw-88d969da9f1aa421 records the exact tenant lock, immutable openupgradelib and simple-zpl2 commits, canonical package identities, and installed package inventory. External requirements compatibility remains explicit evidence rather than hidden tenant ownership.

No dependency-policy work remains. OPW live onboarding and lifecycle proof remains correctly separate in cbusillo/launchplane#1664 and did not block artifact completion.

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.
• Define Launchplane artifact evidence for lockfile hashes, final installed package inventory, base/platform identity, source attribution, and unlocked external inputs.
• Resolve OPW simple_zpl2 floating master risk through a full immutable commit pin and schema-v2 evidence.

Relationships

• Native subissues:
  • cbusillo/launchplane#1763 — artifact dependency-provenance schema and read evidence.
  • cbusillo/odoo-docker#59 — frozen support/runtime plus tenant-lock installation and evidence generation.
  • cbusillo/odoo-devkit#80 — dependency workspace validation, immutable staging, and manifest emission.
  • cbusillo/odoo-tenant-cm#105 — CM tenant lock and first artifact pilot.
  • cbusillo/odoo-tenant-opw#101 — OPW tenant lock, VCS pinning, and follow-up pilot.
• cbusillo/odoo-devkit#80 is blocked by cbusillo/launchplane#1763 and cbusillo/odoo-docker#59.
• cbusillo/odoo-tenant-cm#105 is blocked by cbusillo/odoo-devkit#80 for its artifact proof.
• cbusillo/odoo-tenant-opw#101 follows the CM pilot and remains blocked by explicit OPW onboarding evidence in cbusillo/launchplane#1664 for full live validation.
• Tenant workflow-thinning plans cbusillo/odoo-tenant-cm#21 and cbusillo/odoo-tenant-opw#31 remain downstream of this policy work.

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

• Use a two-layer dependency model:
  • odoo-devkit retains a separate frozen uv lock for support/runtime startup dependencies.
  • Each tenant repo owns one root uv workspace and committed uv.lock for all owned tenant/shared-addon Python runtime dependencies.
• Tenant root projects and addon workspace members use package = false; managed = false is not the final contract because it excludes those projects from workspace locking.
• Owned addon dependency metadata remains close to each addon. Devkit validates complete workspace membership, lock freshness, and immutable direct references instead of duplicating dependency intent into a central checked-in catalog.
• Production export uses frozen all-workspace semantics. Owned addon metadata may be installed with --no-deps, but no owned-addon operation may invoke a second resolver after the tenant lock.
• External third-party addon repositories remain an explicit compatibility lane only when their source ref is exact. Their dependency files are hashed and their resolver use is recorded as external/unlocked evidence rather than misrepresented as tenant-lock coverage.
• New direct VCS dependency declarations require full commit SHAs. OPW will preserve current simple_zpl2 behavior by pinning commit 177de4500279034d7bf4b6a8ba0244730d9c1219; fork/vendor/replace only if maintenance evidence later requires it.
• Launchplane artifact-manifest schema v2 records:
  • support/runtime and tenant lock source/path/SHA-256 evidence;
  • platform-keyed Python version and canonical installed package/source inventory plus digest;
  • sanitized exact VCS commit metadata;
  • explicit external compatibility input descriptors;
  • existing base-image and build-tool provenance.
• Historical v1 artifacts remain readable. After coordinated rollout, new Odoo publishes fail closed without complete v2 evidence.
• Hash exact staged lock bytes and validate clean source commits plus immutable base-image digests before build/push. The manifest must describe the bytes and digests actually built.
• Run final uv pip check; raw pip freeze text, credentials, authenticated URLs, local absolute paths, and token-bearing query strings are never persisted.
• Pure addon repos with no runtime Python dependencies do not need their own deployable lock. Their source identity remains artifact input evidence.
• Launchplane records dependency evidence but does not resolve tenant dependencies; odoo-docker owns generic installation, odoo-devkit owns validation/staging, and tenant repos own dependency intent and final tenant locks.

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?