(WIP) add HuggingFace-style AutoEnv and AutoAction classes

[wukaixingxp]

This PR creates HuggingFace-style AutoEnv and AutoAction classes, so that it will be easier for a general training framework (eg. TorchForge) to import any env from a modular yaml like:

openenv_config:
  docker_image: "coding-env:latest"
  env_vars: {}
  container_timeout_s: 120.0
  request_timeout_s: 60.0
  container_memory_gb: 64
  port: 8000
  num_worker: 4

Details for this PR:
1.AutoEnv class with HuggingFace-style API

• Automatic environment detection from Docker image names or a name
• Methods:
  • from_docker_image() - Create env from image (with custom timeout!)
  • from_hub() - Create env from HuggingFace Hub
  • list_environments() - Show all available environments
  • get_env_info() - Get detailed environment information
  • from_name() - Create env from name

2. AutoAction class for automatic Action class retrieval

• Methods:
  • from_env() - Get Action class by environment name
  • from_image() - Get Action class from Docker image
  • list_actions() - Show all available Action classes
  • get_action_info() - Get Action class information

3. Added wait_timeout parameter** (default: 30.0 seconds)

• Automatic cleanup on timeout - containers are stopped/removed if they don't start
• Better error messages with container logs

Before (Old Way)

from envs.coding_env import CodeAction, CodingEnv

client = CodingEnv.from_docker_image("coding-env:latest")
action = CodeAction(code="print('Hello')")

After (New HuggingFace-Style API)

from envs import AutoEnv, AutoAction

# Automatically detect and create environment
client = AutoEnv.from_docker_image("coding-env:latest")

# Get the Action class automatically
CodeAction = AutoAction.from_image("coding-env:latest")

# Or get by environment name
CodeAction = AutoAction.from_env("coding")

# Use them together
action = CodeAction(code="print('Hello')")
result = client.step(action)
client.close()

Let me know if there is any suggestions on this feature, I just want to make OpenEnv user-friendly for RL training.

TODO:

1. add more tests on this.
2. will provide a example in TorchForge on how to use this feature.

[burtenshaw]

This looks really cool, but the mapping in registry concerns me because we would need to maintain this here.

To give more context, we expect for there to be thousands of envs on registries like the hf hub, and just a few gold standard examples in the repo. Could we implement AutoEnv without the registry mapping? For example, by using a remote_code style extraction of the client class from the space repo on hf?

[wukaixingxp]

This looks really cool, but the mapping in registry concerns me because we would need to maintain this here.

To give more context, we expect for there to be thousands of envs on registries like the hf hub, and just a few gold standard examples in the repo. Could we implement AutoEnv without the registry mapping? For example, by using a remote_code style extraction of the client class from the space repo on hf?

Thanks for the suggestion, let me take a close look at how HF remote_code style extraction works.. this means we need to update every env to have those info saved.

[burtenshaw]

This looks really cool, but the mapping in registry concerns me because we would need to maintain this here.

To give more context, we expect for there to be thousands of envs on registries like the hf hub, and just a few gold standard examples in the repo. Could we implement AutoEnv without the registry mapping? For example, by using a remote_code style extraction of the client class from the space repo on hf?

Thanks for the suggestion, let me take a close look at how HF remote_code style extraction works.. this means we need to update every env to have those info saved.

Yes, potentially. But the envs already contain the client classes and use a consistent structure. So we could leverage that. You might want to take a look at #160 .

Also, because the envs will be python projects, it is possible to install them via pip.

[wukaixingxp]

This looks really cool, but the mapping in registry concerns me because we would need to maintain this here.
To give more context, we expect for there to be thousands of envs on registries like the hf hub, and just a few gold standard examples in the repo. Could we implement AutoEnv without the registry mapping? For example, by using a remote_code style extraction of the client class from the space repo on hf?

Thanks for the suggestion, let me take a close look at how HF remote_code style extraction works.. this means we need to update every env to have those info saved.

Yes, potentially. But the envs already contain the client classes and use a consistent structure. So we could leverage that. You might want to take a look at #160 .

Also, because the envs will be python projects, it is possible to install them via pip.

Thanks for pointing out this PR #160, after reviewing it, I think I will wait for this PR to be merged into main then add my feature on top of it then.