## Summary
- Problem: `envpool.entry` silently ignored `ImportError` while
importing registration modules, so real registration import failures
could be hidden as missing environments.
- Scope: Remove the entry-level `try`/`except ImportError` wrappers and
keep direct registration imports. This does not change Procgen's
narrower internal Qt runtime soft-fail path.
- Outcome: Registration import failures now fail fast at `import
envpool`, while Procgen's Linux Qt error remains handled inside
`envpool.procgen`.

This reverts the broad entry-level lazy import behavior that was
introduced for a Procgen Qt dependency issue after the Procgen-specific
handling and platform wheel support moved elsewhere.

## Technical Details
- Approach: Replace repeated `try`/`except ImportError: pass` blocks
with direct imports for all environment registration modules.
- Code pointers:
- `envpool/entry.py`: imports each registration module directly so
registration errors surface immediately.
- Notes: `envpool/procgen/__init__.py` still owns the targeted Linux Qt
runtime error path.

## Test Plan
### Automated
- `python3 -m compileall envpool/entry.py envpool/procgen/__init__.py`:
passed
- `python3 -m ruff check envpool/entry.py`: passed
- `git diff --check -- envpool/entry.py`: passed
- Not run: full `import envpool` smoke against this local source
checkout because the compiled extension modules are not built locally.

### Suggested Manual
- `make release-test-procgen-qt PROCGEN_QT_RUNTIME=absent`: verify Linux
no-Qt Procgen smoke behavior still reports the targeted Qt runtime hint.

## Summary
- Problem: EnvPool's dm_control coverage was missing tasks from
`dm_control==1.0.38`, including dog, lqr, quadruped, stacker, and
HumanoidCMU walk.
- Scope: Adds native EnvPool implementations and registration for the
missing DMC suite tasks, plus tests/docs/assets needed to exercise them.
This does not change non-DMC APIs.
- Outcome: EnvPool now registers the full `suite.ALL_TASKS` set for
`dm_control==1.0.38`, including normal and pixel variants for the new
domains.

This diff completes the dm_control suite task set in EnvPool and
tightens alignment coverage for both existing and newly added Mujoco DMC
tasks.

## Technical Details
- Approach: Implemented new C++ task headers for dog, lqr, quadruped,
and stacker by mirroring dm_control 1.0.38 task semantics, then wired
them through pybind registration, Python env wrappers, task
registration, XML generation, and the docs.
- Code pointers:
- `envpool/mujoco/dmc/dog.h`: dog task initialization, observations,
rewards, fetch ball state, and contact sensor handling.
- `envpool/mujoco/dmc/lqr.h`: LQR XML generation, action bounds,
randomized stiffness alignment, and rewards.
- `envpool/mujoco/dmc/quadruped.h`: quadruped terrain/fetch/run/walk
logic, including fetch ball body-state alignment.
- `envpool/mujoco/dmc/stacker.h`: stacker initialization, target
placement, box observations, and box velocity ordering.
- `envpool/mujoco/dmc/utils.cc`: XML transforms for dog, lqr, quadruped,
and stacker task variants.
- `envpool/mujoco/dmc/mujoco_dmc_suite_ext_align_test.py`: alignment
coverage for the newly added domains, with per-key dog contact
tolerances only for `foot_forces`/`touch_sensors`.
- `envpool/mujoco/dmc/mujoco_dmc_suite_align_test.py`: removes an unused
pre-step action sample so align tests do not advance NumPy RNG without
using the action.
- Notes: Dog contact-force observations still need tiny contact-specific
tolerance under MuJoCo v3 because `foot_forces`/`touch_sensors` diverge
at roughly `1e-4` to `1e-3` absolute scale despite synced reset state;
other dog/ext observations stay on the stricter `rtol=1e-7` path.

## Test Plan
### Automated
- `bazel test --config=macos --config=test
//envpool/mujoco:mujoco_dmc_suite_ext_align_test --test_output=errors`:
passed.
- `bazel test --config=macos --config=test
//envpool/mujoco:mujoco_dmc_suite_align_test --test_output=errors`:
passed.
- `bazel test --config=macos --config=test
//envpool/mujoco:mujoco_dmc_suite_ext_deterministic_test
//envpool/mujoco:mujoco_dmc_render_test
//envpool/mujoco:mujoco_dmc_pixel_observation_test
--test_output=errors`: passed.
- `bazel test --config=macos --config=test
//envpool/mujoco:mujoco_dmc_suite_deterministic_test
--test_output=errors`: passed.
- `python -m compileall -q envpool/mujoco/dmc`: passed.
- `git diff --check`: passed.
### Suggested Manual
- `bazel test --config=macos --config=test //envpool:make_test
--test_filter=_MakeTest.test_make_mujoco_dmc`: run in an environment
with `cmake` available; local attempt was blocked while building the
unrelated SDL2/VizDoom dependency because `cmake` was missing.

## Summary
Fixes #55.

The SB3 example adapter currently subclasses `VecEnvWrapper` while
wrapping a raw EnvPool object, which is not itself an SB3 `VecEnv`. That
lets SB3 wrapper attribute lookup recurse through the adapter into the
raw EnvPool object and fail when
`VecMonitor(VecNormalize(VecAdapter(env))).save(...)` looks for
`getattr_depth_check`. This change makes `VecAdapter` the SB3 boundary
by subclassing `VecEnv` directly and implementing the small set of
VecEnv adapter methods needed by SB3 wrappers.

This also updates the README highlights to make the current Linux,
macOS, and Windows wheel support more prominent, calls out built-in
rendering for batched `rgb_array` output and `human` display mode, and
refreshes stale Gym wording so user-facing examples point at Gymnasium
instead of the unsupported OpenAI Gym API.

Key review points:
- `examples/sb3_examples/ppo.py`: changes `VecAdapter` to inherit
`VecEnv` directly, keeps EnvPool behind the adapter, converts batched
EnvPool info dicts into SB3 list-of-dicts, implements the SB3 boundary
methods, and uses `env_type="gymnasium"` in the example path.
- `README.md`: adds prominent highlight bullets for Linux/macOS/Windows
support and rendering support, then updates README API examples and
compatibility copy from Gym to Gymnasium.

## Test Plan
### Automated
- `ruff check examples/sb3_examples/ppo.py`: passed
- `ruff format --check examples/sb3_examples/ppo.py`: passed
- `python -m py_compile examples/sb3_examples/ppo.py`: passed
- `python -m mypy examples/sb3_examples/ppo.py`: passed
- `git diff --check README.md examples/sb3_examples/ppo.py`: passed
- `rg -n 'OpenAI `gym`|supports both
gym|env_type="gym"|openai-gym|make_gym\(|Mujoco \(gym\)|Mujoco'
README.md examples/sb3_examples/ppo.py`: no stale matches
- Ad hoc Python smoke with `envpool==1.1.1` and
`stable-baselines3==2.8.0`, wrapping
`VecMonitor(VecNormalize(VecAdapter(raw)))`, running
`PPO.learn(total_timesteps=16)`, then `env.save(...)`: passed
- Ad hoc Python smoke with `CartPole-v1`, `env_type="gymnasium"`,
`num_envs=2`, and `max_episode_steps=1` to force terminal single-env
resets through `reset(np.array([i]))`, then `env.save(...)`: passed

## Summary
This removes the now-duplicate gym EnvPool wrapper/type layer.
`py_env()` now builds `EnvSpec`, `DMEnvPool`, and `GymnasiumEnvPool`
only; task registration stores only the concrete dm/gymnasium classes;
the obsolete `GymEnvPool` protocol/export is gone; and the public
gym-compatible factories now redirect to the gymnasium factory path. The
public compatibility entrypoints (`make_gym` and `env_type="gym"`)
remain available and return the gymnasium-compatible EnvPool.

Key review points:
- `envpool/python/api.py`: stops importing/building `GymEnvPoolMeta` and
changes `py_env()` to return three classes.
- `envpool/python/protocol.py`: removes the obsolete `GymEnvPool`
protocol and gym-only return aliases.
- `envpool/registration.py`: removes `gym_cls` registration and
canonicalizes public `gym` factory requests to the gymnasium EnvPool.
- `envpool/python/gym_envpool.py`: deletes the obsolete private
meta-wrapper alias module.
- `envpool/*/__init__.py`: stops exporting per-env `*GymEnvPool`
concrete classes.
- BUILD files touched by `make buildifier` are formatted in the repo's
preferred order.
- `docs/content/new_env.rst`: updates new-env instructions to
register/build the gymnasium wrapper only.

Note: Bazel domain tests still keep explicit `import
envpool.<domain>.registration # noqa: F401` imports. Those are required
for tests that depend on a domain registration target without importing
the root `envpool` package/entrypoint.

## Test Plan
### Automated
- `make buildifier`: passed
- `buildifier -mode=check <buildifier-touched files>
envpool/python/BUILD`: passed
- `ruff check <changed non-deleted Python files>`: passed
- `python -m py_compile <changed non-deleted Python files>`: passed
- `git diff --check`: passed
- no exact `GymEnvPool` / `GymResetReturn` / `GymStepReturn` matches
remain: passed
- registry/factory smoke with fake task: passed
- py_env fake-class smoke: passed
- `bazel test //envpool/dummy:dummy_py_envpool_test
--test_output=errors`: not run to target locally; local Bazel repository
setup fails because this checkout is missing
`third_party/pip_requirements/requirements.txt`

## Summary
Fixes #391

EnvPool's XLA GPU custom calls were compiled against the CUDA runtime
and used `cudaMemcpyAsync` / `cudaStreamSynchronize` directly from CPU
wheels. On a JAX CUDA backend this could abort inside the EnvPool FFI
handler before returning from the first jitted `env.xla()` step. This
change treats the XLA platform stream as an opaque pointer, lazily loads
the NVIDIA driver API on Linux, and uses driver-level async copies on
the same stream. CPU import and CPU XLA paths do not load CUDA.

The recv GPU path now synchronizes after host-to-device copies so the
temporary host state buffers stay alive until copies complete. A
MiniGrid XLA smoke test covers the issue's "step without explicit reset"
flow.

Key review points:
- `envpool/core/cuda_driver.h`: Linux-only, lazy libcuda.so.1 loader for
the three driver calls needed by XLA GPU send/recv.
- `envpool/core/xla.h`: replaces runtime-CUDA copies with driver-copy
helpers and synchronizes both action D2H and state H2D transfers.
- `envpool/core/xla_template.h`: binds the XLA FFI platform stream as an
opaque `EnvPoolGpuStream`.
- `envpool/minigrid/minigrid_xla_test.py`: adds a jitted XLA smoke test
for `MiniGrid-Empty-5x5-v0`.

## Test Plan
### Automated
- `ruff check envpool/minigrid/minigrid_xla_test.py`: passed
- `bazel build //envpool/core:xla --config=test`: passed locally
- `bazel build //envpool/core:xla
//envpool/classic_control:classic_control_envpool --config=test`: passed
on Linux devbox
- `bazel build //envpool/classic_control:classic_control_envpool
//envpool/minigrid:minigrid_envpool --config=test`: passed on Linux
devbox
- `bazel test //envpool/minigrid:minigrid_xla_test --config=test
--test_output=errors`: passed on Linux devbox

### Manual
- Reproduced #391 on a GPU devbox with envpool 1.1.1 +
jax/jaxlib/jax-cuda12 0.9.2: CPU XLA passed, GPU jitted
`MiniGrid-Empty-5x5-v0` raw step aborted with rc 134.
- Replaced only the classic_control and minigrid extension modules in
the same venv with Bazel-built patched modules: GPU jitted raw-step
smoke passed for `CartPole-v1` and `MiniGrid-Empty-5x5-v0`.

###### Why/Context/Summary
- Add native C++ EnvPool support for the upstream `highway-env` task
family, including all registered upstream IDs, EnvPool aliases,
deterministic reset/step/render behavior, and a doc-only
EnvPool-vs-official render comparison.
- Keep official `highway_env`/Gymnasium usage out of runtime
implementation; official envs are only used by tests and doc tooling as
an oracle.
- Tighten official alignment coverage, including longer rollouts,
multi-step render checks, intersection and multi-agent cases, plus a
TODO for exposing per-player termination for
`intersection-multi-agent-v1`.

###### Test plan
- `make ruff py-format`: passed
- `make mypy`: passed
- `make clang-format`: passed
- `make cpplint`: passed
- `git diff --check`: passed
- `bazel test --test_output=errors //envpool/highway/...`: passed, 5/5
Highway tests
- `make bazel-test BAZEL_TEST_TARGETS=//envpool:make_test` with
sanitized PATH forwarded through Bazel `action_env` / `host_action_env`:
passed
- `rg` implementation scan for Python bridge/import patterns: no bridge
hits
- `docutils` parse of `docs/env/highway.rst`: passed
- render montage regenerated and checked as PNG (`1320x1296`, RGB)
- GitHub CI `lint`, `clang-tidy`, and CodeQL: passed on the latest
pushed commit

## Description

This PR strengthens environment parity checks across MuJoCo, Box2D,
MiniGrid, and BabyAI. It adds reset-state-synchronized alignment
coverage against the official implementations, expands deterministic
rollouts to run through full episode horizons, and tightens render
checks to use the same synchronized state setup where the official env
exposes enough state.

For Box2D, this also switches the C++ dependency to pybox2d 2.3.10 to
match Gymnasium's Box2D runtime, updates the C++ call sites for the 2.3
API, and adds v3-only Gymnasium alignment for CarRacing, LunarLander,
and BipedalWalker. The extra state fields needed by the tests stay under
ENVPOOL_TEST.

## Motivation and Context

The previous alignment checks could miss semantic drift because several
tests only ran short prefixes or compared after reset without
eliminating differences from random-number implementation details. That
made it possible for EnvPool users to train against behavior that looked
covered by tests but was not comparable with Gymnasium/MuJoCo baselines.

No GitHub issue is linked for this maintenance fix.

- [ ] I have raised an issue to propose this change
([required](https://envpool.readthedocs.io/en/latest/pages/contributing.html)
for new features and bug fixes)

## Types of changes

What types of changes does your code introduce? Put an `x` in all the
boxes that apply:

- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds core functionality)
- [ ] New environment (non-breaking change which adds 3rd-party
environment)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation (update in the documentation)
- [ ] Example (update in the folder of example)

## Implemented Tasks

- [x] Added official alignment checks that sync internal state after
reset before comparing rollouts and reset renders.
- [x] Tightened MuJoCo Gym alignment to v5 and expanded MuJoCo
DMC/robotics deterministic and render coverage.
- [x] Added Box2D v3 Gymnasium alignment and switched the native Box2D
build to pybox2d 2.3.10 for Gymnasium parity.
- [x] Expanded MiniGrid and BabyAI deterministic, alignment, and render
checks to cover full horizons and reset-state sync.

## Checklist

Go over all the following points, and put an `x` in all the boxes that
apply.
If you are unsure about any of these, don't hesitate to ask. We are here
to help!

- [x] I have read the
[CONTRIBUTION](https://envpool.readthedocs.io/en/latest/pages/contributing.html)
guide (**required**)
- [ ] My change requires a change to the documentation.
- [x] I have updated the tests accordingly (*required for a bug fix or a
new feature*).
- [ ] I have updated the documentation accordingly.
- [ ] I have reformatted the code using `make format` (**required**)
- [ ] I have checked the code using `make lint` (**required**)
- [ ] I have ensured `make bazel-test` pass. (**required**)

Validation run locally:

- `python -m ruff check envpool/box2d/box2d_align_test.py
envpool/box2d/box2d_deterministic_test.py
envpool/box2d/box2d_render_test.py
envpool/box2d/box2d_correctness_test.py
envpool/minigrid/babyai_align_test.py
envpool/minigrid/babyai_deterministic_test.py
envpool/minigrid/babyai_render_test.py
envpool/minigrid/minigrid_align_test.py
envpool/minigrid/minigrid_deterministic_test.py
envpool/minigrid/minigrid_render_test.py
envpool/mujoco/dmc/mujoco_dmc_render_test.py
envpool/mujoco/dmc/mujoco_dmc_suite_deterministic_test.py
envpool/mujoco/dmc/mujoco_dmc_suite_ext_deterministic_test.py
envpool/mujoco/gym/mujoco_gym_align_test.py
envpool/mujoco/gym/mujoco_gym_deterministic_test.py
envpool/mujoco/gym/mujoco_render_test.py
envpool/mujoco/robotics/robotics_test.py`
- `buildifier -mode=check envpool/box2d/BUILD envpool/mujoco/BUILD
envpool/workspace0.bzl third_party/box2d/box2d.BUILD`
- `git diff --check`
- `USE_BAZEL_VERSION=8.6.0 bazelisk test --test_output=errors
--config=test --spawn_strategy=local
--action_env=PATH=/opt/homebrew/bin:/bin:/usr/bin:/usr/local/bin
//envpool/box2d:all //envpool/minigrid:all //envpool/mujoco/...`

## Description

Add Google Research Football as `gfootball/xxx-v1` environments backed
by the upstream C++ engine instead of the Python wrapper. This wires the
env into EnvPool registration, builds the upstream engine and assets via
Bazel, and adds a small C++ oracle binding so the EnvPool implementation
can be checked against upstream semantics.

The runtime path stays pure C++.
`envpool/gfootball/gfootball_scenarios.inc` is no longer checked into
the repo; it is now generated at build time from the official upstream
`gfootball/scenarios/*.py` sources via
`third_party/gfootball/generate_scenarios.py`. Likewise, the checked-in
`SDL_ttf` and `SDL2_gfx` sources are removed in favor of upstream
`http_archive` downloads plus thin Bazel BUILD glue and compatibility
headers.

This also adds the test surface expected for a new environment
integration: all registered tasks are covered by bitwise align checks,
bitwise render checks, deterministic checks, and a `make_test` smoke
path. The render bitwise test is present and does not skip any task. On
this local macOS runtime it is still blocked by SDL window creation
(`Invalid window`), but the test itself remains enabled.

Validation run:
- `bazel test //envpool/gfootball:gfootball_align_test
--test_output=errors --verbose_failures --action_env=PATH=...`: passed
- `bazel test //envpool/gfootball:gfootball_deterministic_test
--test_output=errors --verbose_failures --action_env=PATH=...`: passed
- `bazel test //envpool/gfootball:gfootball_render_test
--test_output=errors --verbose_failures --action_env=PATH=...`: fails
locally on macOS with SDL `Invalid window`

## Motivation and Context

We want gfootball support without importing upstream Python at runtime,
since that adds avoidable overhead and makes step and render semantics
harder to keep aligned. This PR keeps the rollout path in C++ while
still reusing the upstream engine code and data directly, and
standardizes the EnvPool ids as `gfootball/<scenario>-v1`.

This change also makes render enablement flow correctly through
`envpool.registration` so render-capable environments can switch their
backend render path on automatically when callers request `render_mode`,
render dimensions, or pixel observations.

- [ ] I have raised an issue to propose this change
([required](https://envpool.readthedocs.io/en/latest/pages/contributing.html)
for new features and bug fixes)

## Types of changes

What types of changes does your code introduce? Put an `x` in all the
boxes that apply:

- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds core functionality)
- [x] New environment (non-breaking change which adds 3rd-party
environment)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation (update in the documentation)
- [ ] Example (update in the folder of example)

## Implemented Tasks

- [x] Add `gfootball/xxx-v1` registrations, the C++ env implementation,
and the pybind entrypoints.
- [x] Generate the scenario config include from upstream gfootball
scenario sources at build time instead of checking in a derived `.inc`
file.
- [x] Pull `SDL_ttf` and `SDL2_gfx` from upstream archives instead of
vendoring their `.c` and `.h` sources in this repo.
- [x] Add align, render, deterministic, and make-time smoke coverage for
the registered gfootball tasks.

## Checklist

Go over all the following points, and put an `x` in all the boxes that
apply.
If you are unsure about any of these, don't hesitate to ask. We are here
to help!

- [ ] I have read the
[CONTRIBUTION](https://envpool.readthedocs.io/en/latest/pages/contributing.html)
guide (**required**)
- [ ] My change requires a change to the documentation.
- [x] I have updated the tests accordingly (*required for a bug fix or a
new feature*).
- [ ] I have updated the documentation accordingly.
- [ ] I have reformatted the code using `make format` (**required**)
- [ ] I have checked the code using `make lint` (**required**)
- [ ] I have ensured `make bazel-test` pass. (**required**)

## Description

This adds a native C++ EnvPool implementation for the Farama MetaWorld
v3 Sawyer manipulation benchmark, pinned to the official
`Farama-Foundation/Metaworld` `v3.0.0` source archive. The new family
registers every `ALL_V3_ENVIRONMENTS` task under the `MetaWorld/`
prefix, keeps `Meta-World/` aliases, wires the MetaWorld MuJoCo XML
assets through `third_party/metaworld_assets`, and documents the
supported task IDs and public space contract.

Key review points:

- `envpool/mujoco/metaworld/metaworld_env.h` contains the native
task/state/reward implementation and all per-task variants.
- `envpool/mujoco/metaworld/tasks.h` centralizes the generated task
metadata for all 50 v3 environments.
- `envpool/mujoco/metaworld/metaworld_align_test.py` reset-syncs once
against the official MetaWorld oracle, then compares step-level
observations, rewards, terminal flags, truncation flags, and exposed
info for every task.
- `envpool/mujoco/metaworld/metaworld_render_test.py` covers reset and
multi-step native rendering across the registered task set.
- `docs/env/metaworld.rst` adds the new family documentation and render
sample.

Validation run:

- `make ruff py-format`
- `make mypy`
- `make cpplint`
- `make clang-format`
- `make buildifier`
- `git diff --check`
- `bazel test --config=debug --test_output=errors
//envpool/mujoco:metaworld_test //envpool/mujoco:metaworld_align_test
//envpool/mujoco:metaworld_render_test`
- devbox: `make docstyle`
- devbox: `make bazel-test BAZEL_TEST_TARGETS=//envpool:make_test`

## Motivation and Context

MetaWorld is a common MuJoCo manipulation benchmark, but EnvPool did not
have a native runtime implementation for it. This ports the full v3 task
family without a Python runtime bridge, so users can run the benchmark
through EnvPool's standard C++ backend, vectorized API, registry, docs,
and packaging flow.

- [ ] I have raised an issue to propose this change
([required](https://envpool.readthedocs.io/en/latest/pages/contributing.html)
for new features and bug fixes)

## Types of changes

What types of changes does your code introduce? Put an `x` in all the
boxes that apply:

- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds core functionality)
- [x] New environment (non-breaking change which adds 3rd-party
environment)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [x] Documentation (update in the documentation)
- [ ] Example (update in the folder of example)

## Implemented Tasks

- [x] Add native C++ MetaWorld v3 task implementations and pybind
registration.
- [x] Add official-oracle alignment, determinism, registry coverage, and
render tests.
- [x] Add third-party MetaWorld asset packaging and documentation.

## Checklist

Go over all the following points, and put an `x` in all the boxes that
apply.
If you are unsure about any of these, don't hesitate to ask. We are here
to help!

- [x] I have read the
[CONTRIBUTION](https://envpool.readthedocs.io/en/latest/pages/contributing.html)
guide (**required**)
- [x] My change requires a change to the documentation.
- [x] I have updated the tests accordingly (*required for a bug fix or a
new feature*).
- [x] I have updated the documentation accordingly.
- [x] I have reformatted the code using `make format` (**required**)
- [x] I have checked the code using `make lint` (**required**)
- [x] I have ensured `make bazel-test` pass. (**required**)