Dependencies prevent usage of library

[cemde]

Runtime dependencies use exact version pins (==), preventing integration with other libraries

Description

All 22 runtime dependencies in meta-agents-research-environments==1.2.0 are pinned to exact versions using ==:

click==8.1.8
datasets==4.0.0
docstring-parser==0.16
fsspec==2024.12.0
huggingface-hub==0.33.4
inputimeout==1.0.4
jinja2==3.1.6
litellm==1.71.1
mammoth==1.8.0
markdownify==0.14.1
mcp[cli]==1.11.0
numpy==2.2.6
pandas==2.2.3
pdfminer-six==20231228
pillow==11.1.0
polars-lts-cpu==1.33.1
puremagic==1.27
pydantic==2.10.6
python-dotenv==1.0.1
python-pptx==1.0.2
rapidfuzz==3.12.1
termcolor==2.5.0

This was also the case in v1.1.0 (37 exact pins) and v1.0.x (which additionally restricted Requires-Python ==3.10.*).

Problem

Exact version pins in a published library make it nearly impossible to use ARE alongside other packages. Any downstream project that depends on a different version of pydantic, pillow, numpy, mcp, jinja2, click, etc. — even a compatible patch release — will fail to resolve.

For example, integrating ARE as an optional dependency in a larger project that also uses other AI/ML libraries is effectively impossible, because those libraries inevitably need different versions of shared transitive dependencies like pydantic, pillow, or numpy. The only workaround is declaring ARE as a conflicting extra and installing it in isolation, which defeats the purpose of offering it as a composable library.

This affects anyone trying to use ARE programmatically as a library (as opposed to running it standalone via are-run / are-benchmark CLI).

Suggested Fix

Replace exact pins in the published package metadata with version ranges that ARE has been tested against. The specific ranges should be determined by the ARE team, but as a starting point, most of these dependencies follow semver and are unlikely to break within a major version. For example:

- pydantic==2.10.6
+ pydantic>=2.10.6,<3
- numpy==2.2.6
+ numpy>=2.2,<3

The exact pins should remain in a lockfile (uv.lock, requirements.txt, etc.) to ensure reproducible CI/CLI builds, but the published package metadata (Requires-Dist in the wheel) should declare the range of versions the library is actually compatible with.

This is the standard recommendation from PyPA: libraries declare compatible ranges in install_requires; applications pin exact versions in lockfiles. The current setup appears to have the lockfile versions copied directly into the package metadata.

Environment

• ARE version: 1.2.0 (same issue in 1.1.0, 1.0.x)
• Python: 3.12
• Installer: uv 0.7.x / pip 25.x