[Bug]: Regression — pyproject license="MIT" + setuptools>=77 build requirement breaks editable install (Windows update fails)

[Automata-intelligentsia]

Summary

On Windows, hermes update fails its Python dependency step because the repo's pyproject.toml declares license = "MIT" (PEP 639 SPDX string form) while pinning setuptools>=77.0,<83 as the build backend — but every setuptools version in that range rejects the bare-string license = "MIT" form under strict PEP 639 validation. The editable build (uv pip install -e . / pip install -e .) dies with:

configuration error: `project.license` must be valid exactly by one definition (2 matches found):
    - keys: 'file': {type: string}   required: ['file']
    - keys: 'text': {type: string}   required: ['text']
GIVEN VALUE: "MIT"

This is a regression: two prior issues addressed the same area and the combined result is broken.

Regression context (please read before closing as duplicate)

• fix(packaging): modernize project.license to PEP 639 SPDX string #38353 (closed 2026-06-03) switched license = { text = "MIT" } → license = "MIT" and raised the build-backend floor to setuptools>=77, on the belief that >=77 accepts the SPDX string form. It does not. setuptools 77–82 require either {text: "MIT"} or a PEP 639 SPDX expression config (plus license-files); the bare string "MIT" is rejected.
• fix(build): upper-bound setuptools build requirement (#36620) #36661 (closed 2026-06-04) upper-bounded the build requirement to <83, "aligning with the dev dependency pin of setuptools==82.0.1." But 82.0.1 is itself in the rejecting range. So both fixes together land in a state where the declared license form is incompatible with the pinned backend.

Net effect: a clean venv (or the isolated build env uv creates during hermes update) cannot build hermes-agent at all. The build only succeeds when the venv happens to contain an older setuptools (<77) or a specifically-pinned 77.0.x, neither of which the current pyproject.toml guarantees.

Environment

• Windows 10/11, git-based install at ~/.hermes/hermes-agent
• Observed at commit 6997dc81 (0 commits behind origin/main, pulled 2026-07-14)
• Venv Python 3.11.9; setuptools present at 65.5.0, but the isolated build env fetches setuptools 77–82 per build-system.requires
• pyproject.toml relevant lines:

  [build-system]
  requires = ["setuptools>=77.0,<83"]
  build-backend = "setuptools.build_meta"
  
  [project]
  license = "MIT"
  license-files = ["LICENSE"]

Repro

1. Fresh or updated git install on Windows.
2. Run hermes update (or uv pip install -e . / pip install -e . in the repo root).
3. The dependency step fails with the project.license validation error above; hermes update then falls back to the ZIP path, which fails with WinError 5 Access denied because the running Desktop app / gateway workers hold .pyd files locked. The install is left half-updated.

Workaround (what we did to recover)

Pin setuptools to the one version in the range that still accepts the bare string, then build with --no-build-isolation:

venv\Scripts\python.exe -m pip install "setuptools==77.0.3"
venv\Scripts\python.exe -m pip install -e . --no-build-isolation

This works because 77.0.3 accepts license = "MIT" as a (deprecated-but-valid) string, whereas 77.1+ rejects it. But it is fragile: the next hermes update re-fetches a fresh setuptools into an isolated build env and breaks again.

Suggested permanent fixes (any one resolves it)

1. Make the license form and the backend version consistent. Either:
   • Keep license = "MIT" and pin the build backend to setuptools==77.0.3 exactly (the last version accepting the bare string), or
   • Switch to the PEP 639 dict form license = { text = "MIT" } (which fix(packaging): modernize project.license to PEP 639 SPDX string #38353 deliberately moved away from) and keep setuptools>=77, or
   • Use the SPDX-expression form with proper license-files and a setuptools that supports it (>=77, but the string form specifically needs care).
2. Add a CI job that actually runs the editable build (pip install -e .) on a clean venv with the pinned build-system.requires, so this regression is caught before release. The previous fixes (fix(packaging): modernize project.license to PEP 639 SPDX string #38353, fix(build): upper-bound setuptools build requirement (#36620) #36661) evidently were not validated against a real isolated build.
3. Make hermes update's dependency step robust to this: when the editable build fails on project.license, fall back to a known-good setuptools pin rather than the ZIP path (which then hits the unrelated WinError 5 file-lock on Windows).

Related

• fix(packaging): modernize project.license to PEP 639 SPDX string #38353 (closed) — switched to license = "MIT" + setuptools>=77; introduced the incompatibility.
• fix(build): upper-bound setuptools build requirement (#36620) #36661 (closed) — upper-bounded to <83 aligning with setuptools==82.0.1; 82.x also rejects the string form, so this cemented the break.
• hermes update (Windows): dependency install runs at PROJECT_ROOT (running-CLI dir), not the extracted install root → uv pip install -e . exit 2 #59850 (open) — related but distinct: Windows hermes update fails uv pip install -e . with exit 2 at PROJECT_ROOT. That is a cwd/layout issue; this report is the setuptools/license validation issue. They may surface through the same update path but have different roots.

Labels (suggested)

type/bug comp/build platform/windows regression P2

[wesleysimplicio]

Tried to reproduce this on current main (6997dc81c) with Python 3.11 and couldn't — the editable install succeeds cleanly in every combination I tried:

• setuptools==81.0.0, --no-build-isolation: succeeds (metadata step + wheel build both pass).
• Full build isolation (pip install -e ., letting pip resolve >=77.0,<83 on its own — it picks 82.0.1, the latest in range): succeeds end-to-end, Successfully installed hermes-agent-0.18.2.
• Whatever setuptools ships with a fresh 3.11 venv today (79.0.1), --no-build-isolation: also succeeds.

So across 79.0.1 / 81.0.0 / 82.0.1 — spanning the low, middle, and high end of the pinned >=77.0,<83 range — license = "MIT" + license-files = ["LICENSE"] builds fine for me. I couldn't get the reported project.license must be valid exactly by one definition error to trigger at all.

This looks like it may already be fixed in newer patch releases within the 77–82 range (setuptools has had several PEP 639 validation adjustments), or there's an environment-specific factor (stale pip/setuptools cache, a pinned lockfile, something in the Windows hermes update flow specifically) that a plain venv doesn't hit. Given I can't reproduce it, I don't want to guess at a fix — flagging what I found in case it helps narrow this down, or in case there's a repro detail I'm missing (exact setuptools patch version at time of failure would help).

[Automata-intelligentsia]

We discovered that the bulk of this issue was related to Hermes chron jobs which ran watcher scripts being orphaned instead of quitting during the update. There were a couple of other issues but those have already been fixed in recent updates so I am closing this issue but may open up a new issue regarding the orphaning of Hermes owned watcher scripts if we run into that issue again in the future. For now we retired those scripts so while this is a bug I'd rather not add to the issue list since our experience may be an edge case.