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: Implementation in progress; 5 of 6 native dependency-policy subissues are complete. The shared producer chain and first real tenant lock/artifact pilot are proven.

Completed foundations now include Launchplane schema v2, the two-lock runtime installer, digest-bound enterprise base provenance, devkit immutable workspace staging/evidence, and cbusillo/odoo-tenant-cm#105 / PR #106. CM's real Linux arm64 artifact passed uv pip check, immutable digest readback, exact source attribution, and Launchplane's live schema validation.

The remaining native child is cbusillo/odoo-tenant-opw#101. OPW remains waiting until the CM artifact is exercised through the Launchplane-owned deployment/maintenance finish line in cbusillo/launchplane#1768 and explicit OPW onboarding evidence is available in cbusillo/launchplane#1664.

Next action: complete the CM Launchplane golden-path proof, then implement OPW's tenant lock and immutable VCS pilot.

Blocked by: nothing at the parent decision layer.

Waiting for: the Launchplane CM lifecycle proof before the final OPW subissue becomes actionable.

Last verified: July 18, 2026.

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

• 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?