chore: allow Python 3.14 by relaxing version constraint

[re2zero]

Updates requires-python from >=3.11,<3.14 to >=3.11,<3.15 to support Python 3.14 installations.

Fixes #1588

[Tomas2D]

Thanks @re2zero! A few points before this can move forward:

1. DCO is failing — please sign off your commits (git rebase --signoff then force-push).
2. Scope is mixed. This PR is titled "allow Python 3.14" but also carries the emitter group_id fix (the same change as your fix(emitter): pass group_id by keyword to avoid str(None) on clone #1598). Please keep this PR focused on the version-constraint change only and drop the emitter edits — that fix belongs in fix(emitter): pass group_id by keyword to avoid str(None) on clone #1598 (or fix(emitter): keep an unset group_id unset when cloning #1582, which we're leaning toward for Emitter.clone() turns an unset group_id into the literal string "None" (Python) #1581). Bundling two unrelated fixes makes both harder to review and merge.
3. Relaxing requires-python to <3.15 alone does not deliver 3.14 support (Python 3.14 support #1588). Before we can claim 3.14 works we'd need: all transitive deps to have 3.14 wheels/support, and a 3.14 entry added to the CI test matrix so it's actually exercised. A one-line constraint bump would let users install on 3.14 without any guarantee it runs. Could you scope this to also add 3.14 to CI and confirm the suite passes there?

Appreciate you pushing on 3.14 — it's wanted. 🐝

[Tomas2D]

Update: the emitter group_id fix has landed on main via #1582, so the emitter changes here are now redundant and will conflict. To move this forward, please rebase onto main, drop the emitter edits, and keep only the Python 3.14 work — and note the CI run just failed, so it'll also need the 3.14 CI-matrix addition discussed above before it can go green. Thanks @re2zero! 🐝

[Tomas2D]

Thanks — and note this PR is doing more than the title suggests, in a good way.

The Emitter.clone() change is a real bug fix independent of the version bump: cloning passed arguments positionally and wrapped the group id in str(...), so an emitter with _group_id is None came back from clone() with the literal string "None" as its group id, which then leaked into every EventMeta.group_id. The switch to keyword arguments plus the regression test is correct. Consider calling that out in the PR title/description (or splitting it), since it's worth backporting attention on its own.

Two things before this can go in:

1. The branch has conflicts with main (mergeable: CONFLICTING) — please rebase.
2. Justify the <3.15 bound. Per #1588, litellm now declares <3.15, which was the original blocker, but relaxing our own bound only helps if the whole dependency tree resolves and the suite is green on 3.14. Ideally CI should actually run a 3.14 job as part of this change — otherwise we'd be advertising support we don't test. If adding a 3.14 matrix entry is out of scope here, please at least paste a full unit-suite run on 3.14.

Related: #1588.

[Tomas2D]

Correction to my earlier review — I was wrong about the Emitter.clone() change, and I'd rather you didn't act on that advice.

I said it was a real bug fix worth calling out separately in the title or splitting into its own PR. It isn't: that fix already landed on main in ede230c (#1582, merged 19 Aug), which closed #1581. Your own #1598 proposing the same fix was closed at the time for the same reason.

I misread the diff — its context lines reflect this branch's merge base rather than current main, and I didn't check main before commenting. That's also the direct cause of the conflict here: the branch is re-applying a change that's already upstream.

So the actual ask is the opposite of what I wrote. On rebase onto current main:

• Drop the emitter.py change and the test_clone_without_group_id test — both are already there.
• What should remain is just the requires-python = ">=3.11,<3.15" one-liner, which makes this a genuinely small PR.

My second point stands unchanged: relaxing the bound only helps if the whole dependency tree resolves and the suite is green on 3.14, so this should come with a 3.14 CI matrix entry or a pasted full unit-suite run on 3.14. Sorry for the detour.

Related: #1588, #1581, #1582.

[Tomas2D]

Thanks for taking this on. Two separate things here, and I think the PR is blocked on something upstream rather than on anything you can fix in this diff.

Relaxing requires-python alone isn't enough — litellm caps at <3.14.

Grepping the current lock file for deps that exclude 3.14:

package	python-versions	optional?
litellm	<3.14,>=3.10	no — core dependency
agentstack-sdk	<3.14,>=3.11	yes (agentstack, beeai-platform)
unstructured	<3.14,>=3.11	yes
outlines	<3.14,>=3.10	yes
cz-commitizen	>=3.11,<3.14	dev

litellm is declared as litellm = "^1.84.0" in [tool.poetry.dependencies] with no optional = true, so it's pulled in by every install. Widening requires-python to <3.15 makes the framework's metadata claim 3.14 support, but poetry lock then has to resolve a core dep that refuses to install on it. Until litellm ships a release that allows 3.14, this can't actually work — the constraint here is the symptom, not the cause.

Immediate CI failure (log):

pyproject.toml changed significantly since poetry.lock was last generated. Run `poetry lock` to fix the lock file.

poetry.lock still carries python-versions = ">= 3.11,<3.14". It isn't in the diff, so it never got regenerated — which is also what would have surfaced the litellm conflict above locally.

The emitter change is a real fix and deserves its own PR. Emitter.clone() passing str(self._group_id) positionally turns a None group id into the literal string "None", and your test_clone_without_group_id pins exactly that. Switching to keyword arguments fixes it and makes the call robust to signature changes. That's unrelated to the version constraint, it's independently mergeable, and it's currently stuck behind a blocked upstream dependency. Splitting it out would get it landed now.

The branch also has conflicts with main at this point.

[Tomas2D]

Status update, since this has been sitting a while and one half of it is now moot.

The Emitter.clone() fix in this PR has already landed independently. ede230cc — fix(emitter): keep an unset group_id unset when cloning (#1582), closing issue #1581 — made exactly the same change on 19 Aug. Current main:

cloned = Emitter(
    group_id=self._group_id,
    namespace=self.namespace.copy(),
    ...

So the str(self._group_id) → "None" bug is fixed, and that part of your diff will now conflict rather than apply. Your analysis of it was right — it just got there by another route while this PR was blocked.

What remains is the requires-python change, which is still blocked upstream. As covered in my earlier review, litellm caps at <3.14 and is a core, non-optional dependency, so widening the constraint can't produce a resolvable lock regardless of what this PR does. That hasn't changed: litellm = "^1.84.0" on current main, still <3.14.

Given that, I'd suggest closing this in favour of tracking the upstream litellm release on #1588, unless you'd prefer to keep it open as a placeholder. If litellm does ship 3.14 support, the constraint bump plus a regenerated poetry.lock is a fresh five-minute PR against main — less work than rebasing this one through the conflict.

Thanks for the emitter catch either way; it was a real bug.