mirror of
https://github.com/PR0M3TH3AN/SeedPass.git
synced 2026-10-28 00:12:04 +00:00
thePR0M3TH3ANandClaude Opus 5
4503b7eee4
The Windows entry of the CI build job has never been able to install from this lockfile, and no arrangement of pip-compile can fix that. The lockfile has to serve Linux, macOS and Windows across Python 3.10-3.12. pip-compile resolves for the one environment it runs on and emits no markers, and two dependencies are environment-conditional: aiohttp needs async-timeout only below 3.11, and portalocker needs pywin32 only on Windows. So every possible pip-compile output is wrong somewhere. A Linux/3.11 lockfile killed Windows with "must have their versions pinned" for pywin32; a Windows/3.10 one could never match the diff on the other platforms. Both failure modes turned up in this session, one after the other, as each fix exposed the next. `uv pip compile --universal` resolves across all target environments and emits the markers — `pywin32 ; sys_platform == 'win32'`, `async-timeout ; python_full_version < '3.11'` — pinned and hashed, so one file covers everything. This changes the lock GENERATOR from pip-tools to uv, which is a real tooling decision and worth saying plainly. What it does not change is the consumer: the output is an ordinary pip requirements file, and every build job still installs it with plain `pip install --require-hashes -r requirements.lock`. Nothing depends on uv at install time, so reverting means regenerating the file, not unpicking anything. uv is pinned to 0.10.4 so the regenerate-and- diff stays deterministic. Verified locally: regenerating produces a byte-identical file, and it installs under --require-hashes on both 3.10 and 3.11. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01Vtx94nXDmNgXEeThUZP4QN