packaging: remove redundant core/cli/all extras; migrate envs to plain openenv

[sergiopaniego]

Summary

pip install openenv already installs the full feature set, so the core/cli/all extras were redundant aliases of it (openenv[core] == openenv). This removes them and migrates every in-repo environment from openenv[core] to plain openenv, regenerating each env's lockfile (which also clears stale openenv-core/meta-pytorch lock entries left over from the package rename). Base dependencies are unchanged, so the installed set is identical, this is purely de-duplication. Closes #870.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation
• Refactoring

Alignment Checklist

• I have read .claude/docs/PRINCIPLES.md and this PR aligns with our principles
• I have checked .claude/docs/INVARIANTS.md and no invariants are violated
• I have run /pre-submit-pr (or bash .claude/hooks/lint.sh and tests) and addressed all issues

RFC Status

• Not required

Test Plan

• All 35 environments migrated; each lockfile regenerated and consistent (uv sync --frozen spot-checked).
• tests/test_cli + backfill: 84 passed (init assertion updated; legacy push/validate/backfill tests kept).
• sync_env_docs.py --check passes.
• Removing a published extra is non-fatal: openenv[core] on this version emits a pip warning and installs the base (which is everything).

Breaking change / notes for reviewers

• openenv[core], openenv[cli], openenv[all] no longer exist. External consumers (forks, deployed Spaces) get a harmless pip warning and still install; the installed set is unchanged since these were redundant.
• scripts/prepare_hf_deployment.sh: the dependency-pinning sed now matches both openenv and openenv[core], portable across GNU/BSD sed. Verified on a real migrated env's pyproject (rewrites openenv>=X to a pinned git+...@<ref>, leaves other deps untouched); the HF build/upload step is unchanged by this PR.
• carla_env: requires-python bumped >=3.10 → >=3.11 (its carla-ue5-api==0.10.0 extra already required 3.11, so the env was unsatisfiable on 3.10). Needed to regenerate its lock.
• openenv-core back-compat in src/ and the legacy CLI tests are intentionally kept.
• Breaking: the next release should bump the minor version and note the removed extras.

Claude Code Review

N/A

---

Note

Medium Risk
Breaking install spec for external consumers and deployed Spaces using openenv[core]; runtime behavior should be unchanged but release notes and minor version bump matter.

Overview
Removes redundant core, cli, and all optional extras from the root openenv package (they duplicated the default install) and updates docs so pip install openenv is the single documented path for the full runtime.

In-repo environments (35 total, per PR description) now declare openenv>=… instead of openenv[core] or openenv-core, including the env scaffold template and requirements.txt snippets; lockfiles were regenerated to drop stale openenv-core / meta-pytorch entries from the rename.

Docs (getting-started, contributing envs, Unity deps) no longer mention openenv[core] or the removed extras table rows; optional extras are limited to integrations like inspect and cloud providers.

Breaking: pip install openenv[core|cli|all] will fail on versions that ship this change (older pins may only get a pip warning). Installed dependency sets are intended to stay the same. Related tooling updates noted in the PR include HF deployment sed matching plain openenv, carla_env requires-python >=3.11, and CLI test expectations for init/validate.

^{Reviewed by Cursor Bugbot for commit 1134a39. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want higher recall? High effort reviews run extra passes and find more bugs. A team admin can switch effort levels in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 4ad6497. Configure here.}

[bot-ci-comment]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[cursor]

Alignment Review Report

Two-tier review of the packaging cleanup (remove redundant core/cli/all extras; migrate envs to plain openenv).

Automated Checks

• Lint: PASS for this PR. lint.sh does report formatting diffs, but every one is in a pre-existing envs/**/*.py file this PR does not touch (e.g. chat_env/models.py, opencode_env/*). The only .py file changed here — tests/test_cli/test_init.py — is clean. No lint issues are introduced by this PR.
• Debug code: CLEAN for this PR. check-debug.sh findings are all pre-existing print()/TODO lines in src/ modules untouched by this PR. None introduced.
• Targeted tests: PASS. Ran the directly-affected suites — test_init, test_validate, test_push, test_backfill_openenv_pypi — 84 passed.

Open RFCs Context

All RFCs are pre-1.0 design docs: 000–005 are In Review, 010 is Draft. None concern packaging, dependency extras, or the install surface. Per rfcs/README.md, "minor refactoring" doesn't require an RFC. Nothing here overlaps an open RFC.

Tier 1: Fixes Required

None.

Why this is safe: the removed core/cli/all extras were exact duplicates of packages already in the base [project].dependencies. Since extras are additive, openenv[core] and plain openenv already resolved to an identical dependency closure — so removing them changes nothing about what actually gets installed. Verified the base dependencies array is unchanged via git show <base>:pyproject.toml. The remaining extras (inspect, daytona, aca, modal) and the docs table are consistent.

Tier 2: Alignment Discussion

Principle Conflicts

None identified. This is packaging-only — it does not touch the Gym-like API (reset/step/state), the MCP/agent boundary, reward computation, client/server separation, or the Pydantic/type-safety invariants.

RFC Conflicts

None identified.

Minor / Non-blocking Observations

1. Unrelated scope — carla Python bump. envs/carla_env/pyproject.toml also bumps requires-python >=3.10 → >=3.11. carla is the only env changed this way and it's unrelated to the extras removal. Worth confirming it's intentional (e.g. a dep surfaced during lock regeneration) or splitting it out so the packaging change stays focused. (suggested: @sergiopaniego)
2. Stale-but-passing test fixtures still reference openenv[core]: tests/test_cli/test_push.py:46, tests/test_cli/test_validate.py:258, tests/scripts/test_backfill_openenv_pypi.py:83. These pass because _validation.py/build.py use a regex (^openenv(?:\s*(?:$|[<>=!~@;])|\[)) that matches both openenv and openenv[core], and the backfill test intentionally exercises the legacy openenv-core→openenv rename. Updating the first two would improve consistency; the backfill one can stay as-is.
3. Deploy-script regex (prepare_hf_deployment.sh) now rewrites openenv, openenv[core], and openenv @ git+…. It won't rewrite other-extra forms (e.g. openenv[inspect]) or a bare "openenv" with no specifier — but that matches the previous behavior, so no regression. (suggested: @burtenshaw, author of pin_openenv_refs_in_pyproject)

Summary

• 0 mechanical issues to fix
• 0 alignment points for human review
• 0 RFC conflicts to discuss
• 3 minor, non-blocking observations (1 scope question, 2 consistency nits)

Net: a clean, low-risk packaging cleanup. The extras were genuinely redundant, so the installed footprint and CI behavior are unchanged.

  

_{Sent by Cursor Automation: Untitled}

[cursor]

Unrelated to the extras removal: this bumps requires-python from >=3.10 to >=3.11, and carla is the only env changed this way in the PR.

Was this intentional (e.g. a dependency surfaced during lockfile regeneration that now needs 3.11), or incidental scope creep? Consider confirming it or splitting it into its own commit/PR so the packaging change stays focused.

[sergiopaniego]

intentional :)

[cursor]

Looks correct — this now covers both openenv[core]>=… and plain openenv>=…, plus the @ git+… form (the space is in the [<>=~! @] class).

Non-blocking FYI for completeness: other-extra forms like openenv[inspect]>=… and a bare "openenv" with no version specifier still won't be rewritten to the pinned git ref. That matches the previous regex's behavior (no regression) — just noting it in case an env ever declares the runtime with a different extra.