Fix core dependency constraint blocking compatible plugin upgrades

[he-yufeng]

Problem

The core dependency protection mechanism pins dependencies to the exact installed version using ==:

constraints.append(f"{name}=={installed[name]}")  # e.g. aiosqlite==0.21.0

This prevents plugins from installing newer compatible versions. For example, a plugin requiring aiosqlite>=0.22.1 fails with:

DependencyConflictError: 检测到核心依赖版本保护冲突。
冲突详情: aiosqlite>=0.22.1 vs (constraint) aiosqlite==0.21.0

Even though 0.22.1 >= 0.21.0 and is backward-compatible.

Fix

Change == to >= in the constraint generation:

constraints.append(f"{name}>={installed[name]}")  # e.g. aiosqlite>=0.21.0

This preserves the protection against downgrades (plugins can't install older versions than what's running) while allowing compatible upgrades.

Fixes #6420

Summary by Sourcery

Bug Fixes:

• Allow plugins to install newer compatible versions of core dependencies by changing exact version pinning to a minimum-version constraint.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• Changing == to >= broadens the allowed range considerably; consider whether you also need an upper bound (e.g. < next major) or another mechanism to guard against potentially breaking future major versions being pulled in by plugins.
• The bare except Exception: continue around constraint generation can hide unexpected issues; if feasible, narrow the exception type or at least log the exception so that silent failures in constraint building are observable.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Changing `==` to `>=` broadens the allowed range considerably; consider whether you also need an upper bound (e.g. `<` next major) or another mechanism to guard against potentially breaking future major versions being pulled in by plugins.
- The bare `except Exception: continue` around constraint generation can hide unexpected issues; if feasible, narrow the exception type or at least log the exception so that silent failures in constraint building are observable.

## Individual Comments

### Comment 1
<location path="astrbot/core/utils/core_constraints.py" line_range="83-85" />
<code_context>
             name = canonicalize_distribution_name(req.name)
             if name in installed:
-                constraints.append(f"{name}=={installed[name]}")
+                # Use >= instead of == so plugins can pull in newer compatible
+                # versions while still preventing downgrades below what's installed.
+                constraints.append(f"{name}>={installed[name]}")
         except Exception:
             continue
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Relaxing from == to >= may undermine reproducibility and allow incompatible major upgrades.

Switching from an exact pin to a lower bound means different environments may resolve to different versions over time, which weakens reproducibility and can allow breaking major upgrades (e.g., `1.5` installed but `>=1.5` allows `2.x`). If the goal is to avoid downgrades while allowing safe upgrades, consider either a bounded range like `>=installed,<next_major` or keeping strict pins here and letting plugins declare more permissive requirements. Also verify whether this change is consistent with any expectations of deterministic resolution for this function.

Suggested implementation:

```python
            if name in installed:
                # Use a bounded range (>=installed,<next_major) so that:
                # - we prevent downgrades below the currently installed version
                # - we avoid unbounded major upgrades that may be incompatible
                installed_version = installed[name]
                try:
                    major = int(str(installed_version).split(".")[0])
                except (ValueError, TypeError):
                    # If we cannot parse a simple major version, fall back to
                    # an exact pin to preserve deterministic behavior.
                    constraints.append(f"{name}=={installed_version}")
                else:
                    next_major = major + 1
                    constraints.append(f"{name}>={installed_version},<{next_major}")

```

Depending on the rest of the codebase, you may also want to:
1. Update or add tests that assert the constraint format, e.g. installed `1.5.2` leads to `>=1.5.2,<2`.
2. Ensure any documentation or comments describing this function’s determinism/reproducibility are updated to reflect the bounded-range behavior.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[LIghtJUNction]

测试了吗

[he-yufeng]

Tested locally — here's what I verified:

from packaging.requirements import Requirement

# simulate installed versions
installed = {"aiohttp": "3.9.1", "pydantic": "2.5.0", "numpy": "0.9.3"}

for ver in installed.values():
    try:
        next_major = int(str(ver).split(".")[0]) + 1
    except (ValueError, TypeError):
        print(f"==fallback")
    else:
        print(f">={ver},<{next_major}")

# Output:
# >=3.9.1,<4
# >=2.5.0,<3
# >=0.9.3,<1

Also updated to use bounded >=installed,<next_major instead of plain >= — see latest commit. This way plugins can still upgrade within the same major but won't pull in breaking 2.x when 1.x is installed.