[2/2] Decouple Envs from version: Update /fix / pin all envs 0.2.0

[burtenshaw]

⚠ Pr is pointed not pointed at main

Summary

Sorry, this is a big PR mainly by codex. This implements fixes and pins accross all envs so that they deploy to the hub in their current state. As reflected in this collection: https://huggingface.co/collections/openenv/openenv-environment-hub-v210

[greptile-apps]

Greptile Summary

Large cross-cutting PR that updates all environments for standalone HuggingFace Spaces deployment with OpenEnv 2.2.0. Key changes:

• Deployment scripts rewritten: prepare_hf_deployment.sh now handles multi-env deployment, version pinning, base image substitution, and collection management in a single unified script. Old deploy_to_hf.sh and convert_env.sh are removed.
• Dependency pinning: Several pyproject.toml files switch from git+https://...@main to PyPI openenv-core[core]>=0.2.1 for reproducible builds.
• Import path fixes: Multiple environments update import fallback chains to support both in-repo (openenv.*) and standalone (openenv_core.*) deployment contexts. The openenv_core path is a deprecated compatibility shim.
• Lazy imports: finrl_env, grid_world_env, and openapp_env __init__.py files switch from eager to lazy __getattr__-based imports to avoid pulling in heavy dependencies at package init.
• FinRL decoupling: finrl_env/models.py replaces canonical Action/Observation imports with inline Pydantic stubs to remove the openenv-core dependency, at the cost of potential type drift.
• Chat tokenizer fallback: ChatEnvironment adds a _tokenize_conversation helper with fallback for tokenizers lacking chat_template, but the constructor guard still rejects such tokenizers (bug).
• DIPG V2 rewards: Adds process-supervised reward parameters, a proof channel, and a bundled sample dataset so the env can start without external data.
• Git env defaults: Removes mandatory env var validation for Gitea credentials, replacing with hardcoded defaults. Functional but reduces deployment safety.

Issues Found

1. Bug (chat_env): Constructor rejects tokenizers without apply_chat_template, but the new fallback method handles them. The guard is too strict.
2. Style (finrl_env): Inline Action/Observation stubs duplicate the canonical types and may drift over time.
3. Style (snake_env, websearch_env): Bare except TypeError in create_app calls will mask unrelated errors.
4. Style (git_env): Hardcoded default Gitea credentials without any warning when defaults are used.

Alignment Review

No invariant violations were identified. The changes do not expose reset/step via MCP, do not break client-server separation, and reward computation remains inside environments. The finrl_env inline type stubs are a pragmatic deployment choice but should be tracked for future alignment with canonical types.

Confidence Score: 3/5

• Mostly safe deployment-focused changes, but contains a logic bug in chat_env and some patterns that mask errors.
• Score of 3 reflects: one concrete logic bug (chat_env constructor guard contradicts its own fallback), several instances of broad exception catching that will mask debugging, and hardcoded default credentials without warnings. The bulk of the changes (Dockerfile updates, pyproject.toml pinning, deployment scripts) are safe and well-structured.
• Pay close attention to envs/chat_env/server/chat_environment.py (logic bug in constructor guard), envs/git_env/server/app.py (default credentials), and envs/finrl_env/models.py (type drift risk from inline stubs).

Important Files Changed

Filename	Overview
envs/chat_env/server/chat_environment.py	Adds _tokenize_conversation fallback for tokenizers without chat_template, but the __init__ guard (line 45-46) still rejects tokenizers that lack apply_chat_template, contradicting the new fallback logic.
envs/dipg_safety_env/server/app.py	Major refactor: adds V2 reward parameters, sample dataset fallback, new channel configuration. Constructor signature verified against DIPGEnvironment. All parameters match.
envs/finrl_env/models.py	Replaces openenv.core.env_server.types.Action/Observation imports with inline Pydantic stubs. This decouples from openenv-core but introduces duplicated base classes that could drift from the canonical definitions.
envs/finrl_env/server/finrl_environment.py	Same try/except import pattern for core.env_server vs openenv.core.env_server. Consistent with app.py changes.
envs/git_env/server/app.py	Replaces mandatory env var validation with hardcoded default credentials (openenv/openenv) for Gitea. Security concern with default credentials in production.
envs/openapp_env/server/Dockerfile	Adds beartype/fastmcp dependencies and a second pip install to upgrade them. Functional but the double-install approach is fragile.
envs/snake_env/server/app.py	Adds try/except pattern to handle both class and instance arguments to create_app. The except-on-TypeError approach silently masks unrelated TypeErrors.
envs/websearch_env/server/app.py	Same try/except class-vs-instance pattern for create_app. Import changed to use openenv_core directly (not via try/except).
scripts/manage_hf_collection.py	Enhanced to support versioned collections, explicit space IDs, and optional HF_TOKEN. Well-structured refactor with good error handling.
scripts/prepare_hf_deployment.sh	Major rewrite: now handles multi-env deployment, version pinning, base image substitution, collection updates, and comprehensive staging. Well-structured but complex.

Flowchart

flowchart TD
    A[prepare_hf_deployment.sh] --> B{--all or --env?}
    B -->|--all| C[discover_all_envs]
    B -->|--env| D[SELECTED_ENVS]
    C --> D
    D --> E[For each env]
    E --> F[prepare_stage]
    F --> F1[Copy src/ + envs/]
    F1 --> F2[Pin openenv refs in pyproject.toml]
    F2 --> F3[create_environment_dockerfile]
    F3 --> F4[create_readme]
    F4 --> G{DRY_RUN?}
    G -->|Yes| H[Log would deploy]
    G -->|No| I[hf repo create + hf upload]
    I --> J[DEPLOYED_SPACES]
    H --> J
    J --> K{skip-collection?}
    K -->|No| L[manage_hf_collection.py]
    L --> M[resolve_collection_slug]
    M --> N[add_spaces_to_collection]
    K -->|Yes| O[Done]
    N --> O

Loading

_{Last reviewed commit: 5895a08}

[greptile-apps]

_{36 files reviewed, 5 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Additional Comments (1)

envs/chat_env/server/chat_environment.py
Constructor guard contradicts new fallback logic

The new _tokenize_conversation method (line 59) gracefully falls back to tokenizer.encode() when apply_chat_template fails. However, the __init__ guard here still rejects tokenizers that lack apply_chat_template before they ever get a chance to use the fallback. This means tokenizers like GPT-2 (which the fallback comment specifically mentions) will be rejected at construction time.

Either relax this guard to also accept tokenizers with encode, or remove it entirely and let _tokenize_conversation handle the validation:

        if not hasattr(tokenizer, "apply_chat_template") and not hasattr(tokenizer, "encode"):
            raise ValueError("Tokenizer must have 'apply_chat_template' or 'encode' method")

Prompt To Fix With AI

This is a comment left during a code review.
Path: envs/chat_env/server/chat_environment.py
Line: 45:46

Comment:
**Constructor guard contradicts new fallback logic**

The new `_tokenize_conversation` method (line 59) gracefully falls back to `tokenizer.encode()` when `apply_chat_template` fails. However, the `__init__` guard here still rejects tokenizers that lack `apply_chat_template` before they ever get a chance to use the fallback. This means tokenizers like GPT-2 (which the fallback comment specifically mentions) will be rejected at construction time.

Either relax this guard to also accept tokenizers with `encode`, or remove it entirely and let `_tokenize_conversation` handle the validation:

```suggestion
        if not hasattr(tokenizer, "apply_chat_template") and not hasattr(tokenizer, "encode"):
            raise ValueError("Tokenizer must have 'apply_chat_template' or 'encode' method")
```

How can I resolve this? If you propose a fix, please make it concise.