BUG: normalize line endings and drop BOM in the evaluate.py submission check#55
Open
thc1006 wants to merge 2 commits into
Open
BUG: normalize line endings and drop BOM in the evaluate.py submission check#55thc1006 wants to merge 2 commits into
thc1006 wants to merge 2 commits into
Conversation
…n check pack_for_submission compared the local evaluate.py against the copy on main by hashing raw bytes, so a CRLF or BOM-prefixed working tree (common on Windows) hashed differently from GitHub's LF-served file and warned that an unmodified evaluate.py should not be modified. Decode with utf-8-sig and normalize line endings before hashing, so CRLF, a BOM, and a trailing-newline difference no longer false-positive while real modifications are still detected. Addresses #35 (the reported Windows false-positive). The separate branch-skew case (evaluate.py legitimately differs between main and develop, e.g. the #51 logging change) is not covered here and needs its own decision.
thc1006
force-pushed
the
fix/submission-md5-crlf
branch
from
ffdb0c6 to
451ae4f
Compare
thc1006
changed the title
The evaluate.py integrity check in pack_for_submission was a nested closure, so the BOM/line-ending normalization had no way to be tested on its own. Hoist it to a module-level helper (no behavior change, it captured nothing from the enclosing scope) and add tests/test_submission_md5.py. The tests pin both halves of #35: BOM, CRLF, classic-Mac CR, and trailing-newline variants all hash identically, so a Windows checkout no longer false-positives, while real edits (changed return, extra whitespace, added line, renamed function) still change the hash. Guarded with skipUnless like the other runtime tests, since utils imports the rocketpy stack at module top.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Addresses #35.
pack_for_submission()compares your localevaluate.pyagainst the official copy on main, and it was hashing raw bytes. So a CRLF checkout or a UTF-8 BOM (both common on Windows) hashed differently from GitHub's LF-served file, and the "evaluate.py should not be modified" warning fired on a file nobody had touched (the Win 10 case in #35).The fix decodes with
utf-8-sigand normalizes line endings before hashing, so a BOM, CRLF vs LF, and a trailing-newline difference all stop tripping the warning. I checked the other direction too: flipping a return value or adding a stray space still changes the hash, so it doesn't blind the check to real edits.I also pulled the hash helper out of
pack_for_submissioninto a module-level_normalized_md5(it captured nothing from the enclosing scope, so no behavior change) and addedtests/test_submission_md5.py. The test covers both directions: BOM, CRLF, classic-Mac CR, and trailing-newline variants hash identically, and real edits (changed return, extra whitespace, added line, renamed function) all change the hash.One case it deliberately leaves alone: develop's
evaluate.pygenuinely differs from main (e.g. the #51 logging change), so the check still warns there. Submissions go against a release, so warning on a develop checkout is arguably correct rather than a bug. Making develop quiet too is a separate call, comparing against the matching ref instead of hard-coded main. I left #35 open so you can decide whether that belongs here or in its own issue.Base is develop. ruff check, ruff format --check, and the full suite (15 tests, 10 subtests) pass locally on 3.14.