fix(global_config): fail fast when the parent openai version violates nemo-gym's constraint; explicit opt-in for version skew

[michal2409]

Problem

head_server_deps pins the parent process's openai version into every server venv. When the parent environment ships an openai release outside nemo-gym's own constraint (e.g. openai 2.52.x preinstalled in a base image while nemo-gym caps openai<=2.7.2), that pin makes every server venv resolution unsatisfiable. This does not fail cleanly: the dry-run prefetch bakes venvs that contain nothing but pip, and the problem surfaces only at runtime as import errors far from the cause.

Change (after review)

• Fail fast, loudly: the parser now raises ConfigError at parse time when the parent openai violates nemo-gym's constraint, naming both versions and the remedy. This preserves the install-time guarantee the previous behavior intended to give, minus the empty-venv mystery.
• Explicit, scoped skew mode: a new reserved top-level key allow_openai_version_skew: true opts into letting server venvs resolve openai from nemo-gym's own constraint, with a logging.warning naming both versions. Parent and servers exchange requests across the HTTP/JSON boundary, so the skew surface is the JSON contract, not Python type identity — we run this topology in production (parent 2.52.x, servers on the nemo-gym pin) on 64-node RL trainings.
• Requirement-name comparison canonicalized per PEP 503.
• The constraint is read from the installed distribution metadata at runtime (never hardcoded), so pin bumps like chore(deps): pin openai to 2.44.0 #2456 need no change here.

Tests

Parser-level (through get_global_config_dict): compatible parent → pin present in head_server_deps; incompatible parent → ConfigError naming the opt-in key; incompatible parent + opt-in → pin omitted. Plus unit coverage of the constraint matcher (case-insensitive names, marker'd requirements skipped, missing metadata → conservative pin-preserving fallback).

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[ananthsub]

i've added one blocking comment inline on the risk of parent vs child process openAI version differences. previously this would be caught at install time, but now we have a risk of version skew

[cmunley1]

/claude review

[claude]

SHIP — LGTM, no reliability concerns.

Reviewed the openai version-skew gate in global_config.py. It replaces the unconditional openai==<parent> pin with a constraint-aware gate: pin when the parent satisfies nemo-gym's own openai<=2.7.2, hard-fail with a clear ConfigError when it doesn't, or fall back to nemo-gym's resolution behind the explicit allow_openai_version_skew opt-in.

Correctness:

• Distribution name (nemo-gym) and constraint (openai<=2.7.2) match pyproject.toml.
• All failure modes in _nemo_gym_openai_requirement/_openai_version_matches_nemo_gym_constraint (missing packaging, unparseable req, None from requires(), marker'd reqs, PackageNotFoundError) conservatively return True, preserving the original pin-the-parent behavior. packaging is correctly treated as best-effort via lazy import + broad except.
• prereleases=True avoids false-negative rejections on pre-release parents.
• New allow_openai_version_skew key uses runtime setdefault, consistent with dry_run/skip_venv_if_present — no TypedDict/YAML default divergence.

The one behavioral change — a new default hard-fail on version skew — replaces a silently broken state (dry-run prefetch baking empty venvs) with fail-fast plus a documented escape hatch. Net operability win.

Test coverage is thorough: all three pin/skew/opt-in branches plus the helper's edge cases are exercised. No async, verifier, scorer, reward-aggregation, or public-API surface touched.