packaging 26.3 breaks disabling of source-package constraints (Requirement() now rejects trailing newline)

[jensens]

Symptom

With packaging==26.3 (released 2026-08-04), mxdev no longer comments out constraints for packages declared as sources. The pin survives into constraints-mxdev.txt, and installation then fails because the editable source (a different version) masks the index:

× No solution found when resolving dependencies:
╰─▶ Because there is no version of edutap-wallet-apple==1.0.0a3 and
    you require edutap-wallet-apple==1.0.0a3, we can conclude that your
    requirements are unsatisfiable.

Any CI that installs mxdev fresh (unpinned toolchain) went red the moment packaging 26.3 hit PyPI. mxdev 5.4.0, identical inputs:

• packaging 26.2 → # edutap.wallet_apple==1.0.0a3 -> mxdev disabled (source)
• packaging 26.3 → edutap.wallet_apple==1.0.0a3 (kept!)

Root cause

processing.py (5.4.0, ~lines 124–131) parses the raw requirements/constraints line including the trailing newline:

try:
    parsed = Requirement(line)
except Exception:
    pass
else:
    parsed_name_lower = parsed.name.lower()
    if parsed_name_lower in [k.lower() for k in package_keys]:
        line = f"# {line.strip()} -> mxdev disabled (source)\n"

packaging 26.3 made Requirement parsing stricter — a trailing newline now raises:

>>> Requirement('edutap.wallet_apple==1.0.0a3\n')
# packaging 26.2: parses fine
# packaging 26.3: InvalidRequirement: Expected comma (within version specifier), ...

The bare except Exception: pass swallows it, so the line is silently treated as "not a source package".

Suggested fix

parsed = Requirement(line.strip()) — and possibly log a warning instead of passing silently, so the next parser-behavior change surfaces instead of producing downstream resolver errors.

Happy to send a PR if wanted.

[jensens]

Confirmed. Root cause verified in src/mxdev/processing.py line 125 (process_line()): the raw line — still carrying its trailing newline from file iteration in process_io() — is passed to packaging.requirements.Requirement. packaging 26.3's stricter parser raises InvalidRequirement on the trailing whitespace, and the bare except Exception: pass (lines 126-127) swallows it, so the line is treated as not-a-requirement and never matched against the configured source packages. The other two Requirement() call sites (uv.py:53, config.py:98) already parse stripped strings and are not affected. The existing tests only pass lines without trailing newlines, which is why the suite never caught this.