-
Notifications
You must be signed in to change notification settings - Fork 296
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error out on any changes to files in the repository after generation #159
Conversation
x-ref #158, which should be rebased once this is merged. |
1c8e1ff
to
9c5d309
Compare
To confirm, the point of this check is to ensure that the If that's true, then what's the intended workflow for a change that modifies If we want this level of validation, while still allowing for the possibility of merging changes to the generation before publishing the changed files, we probably need to make |
Yes.
We can make the generation conditional on the current pip version, like only generating the zipapp for pip>=22.3. That would mean landing the PR with the new generation code deactivated at the time of writing. I’d actually prefer to publish it for the current version of pip and test it, while not advertising it and having a cautionary comment in there. It’s easier than having a staging environment and achieves most of the goals we have anyway. |
Cool, I'm completely on board with that. So this PR needs I still need to put together some docs for pip announcing the new |
Disregard the cautionary comment bit, I was thinking of the pyz as a regular text/Python file instead; which it obviously isn’t. :) |
4c051c7
to
157e8fd
Compare
157e8fd
to
f08351a
Compare
This ensures that the generated files match exactly what `generate.py` would generate.
f08351a
to
5326567
Compare
These are difficult to validate re-generation of since the current generation logic isn't versioned.
Alrighty, what should we do with the versioned I've tentatively removed the versioned |
I don’t know if people rely on the versioned pyz files. As long as the unversioned one is there for now, I think that’s ok. But I do think we should work out a solution so we can publish versioned ones (pip version, not python version). I’m afraid I still don’t understand the reasoning behind the way this check works, so I may be being naive, but in my view if the check is giving us issues publishing versioned pyz files, it’s the check that should change, not what we publish. In practical terms, though, I concede that we have no evidence yet that real users care either way 🙂 |
We might also want to add per-version get-pip.py files at that point, which... isn't the worst idea. :) |
This ensures that untracked files are correctly accounted for.