Rename models.py to types.py across all environments

[Copilot]

Problem

The file name models.py in environment directories was causing confusion, as readers typically expect "models" to refer to machine learning models (neural networks, transformers, etc.). However, these files actually contain data type definitions - dataclasses for Action, Observation, and State types used by each environment.

Solution

Renamed all models.py files to types.py across all environments to better reflect their actual purpose. The name "types" clearly indicates these files contain type definitions and is understood by both AI/ML and infrastructure engineers.

Changes

Files Renamed

• src/envs/atari_env/models.py → types.py
• src/envs/coding_env/models.py → types.py
• src/envs/echo_env/models.py → types.py
• src/envs/chat_env/models.py → types.py
• src/envs/openspiel_env/models.py → types.py

Updated References

• All Python imports changed from .models to .types (34 files total)
• Documentation updated in README.md, src/envs/README.md, and environment-specific READMEs
• Docstring examples in core files updated
• File docstrings changed from "Data models" to "Data types" for consistency

Why "types"?

The name types.py was chosen because:

• ✅ Clearly indicates the file contains type definitions
• ✅ Familiar to both AI/ML and infrastructure engineers
• ✅ Aligns with existing patterns in the codebase (core/types.py)
• ✅ Avoids confusion with ML models (neural networks)

Testing

• ✅ Verified all imports work correctly across all 5 environments
• ✅ Confirmed type definitions can be instantiated without errors
• ✅ No breaking changes to existing functionality
• ✅ Security scan passed with 0 vulnerabilities

Example Usage (unchanged)

The API remains exactly the same for users:

from envs.echo_env import EchoAction, EchoEnv

client = EchoEnv.from_docker_image("echo-env:latest")
result = client.step(EchoAction(message="Hello!"))

Users import from the environment package (envs.echo_env), so the internal file rename is transparent to them.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Rename .model() in the spec</issue_title>
<issue_description>As discussed, the reader will expect something very different to be in our model.py files :D Let's rename to something better. Claude can do this task, just creating an issue so we decide what to name it.</issue_description>

<agent_instructions>Use a name that both AI people and infra people will understand.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

Fixes #42

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[meta-cla]

Hi @Copilot!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[pankit-eng]

lets avoid using types.py in general because of conflicting imports that might happen with python std types. Like: cannot import name 'MappingProxyType' from partially initialized module

[Darktex]

@copilot Propose 5 names to use instead of types

[Copilot]

@copilot Propose 5 names to use instead of types

Here are 5 alternative names to replace types.py:

1. schemas.py - Common in API/data modeling, clear that it defines data structures
2. data_types.py - More explicit, avoids stdlib conflict
3. datatypes.py - Single word variant, still explicit
4. structures.py - Indicates data structures, familiar to both audiences
5. protocol.py - Emphasizes the interface/contract aspect

My recommendation: schemas.py - It's widely used in both ML (data schemas) and infrastructure (API schemas), concise, and avoids any import conflicts.