Skip to content
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

Tests: fixup: explicitly unset SOURCE_DATE_EPOCH during 'test_html_multi_line_copyright' #13224

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jayaddison
Copy link
Contributor

@jayaddison jayaddison commented Jan 8, 2025

Purpose

Sphinx's copyright substitution currently allows years identified as the current year to be downgraded to previous years when SOURCE_DATE_EPOCH is configured, to assist reproducibility of documentation builds.

However, we have a test case test_html_multi_line_copyright, written in Y2024, that mentioned a future year - Y2025.

Now that that year is current, it is eligible for substitution when SOURCE_DATE_EPOCH is configured. Many buildsystems, such as those used by Debian and Fedora, choose the most-recent packaging/commit timestamp to use as SOURCE_DATE_EPOCH's timestamp, since those corresponds sensibly to a time-of-build.

However, for the v8.1.3 Sphinx release including the updated substitution logic, the year-of-release/commit was Y2024. Thus, if a commit/packaging date from that year is chosen, and SOURCE_DATE_EPOCH is configured when the unit tests run, the test_html_multi_line_copyright test will fail.

The fix suggested here is to explicitly unset SOURCE_DATE_EPOCH within test_html_multi_line_copyright.

References

Edit: add a reference to the pull request that introduced the bug

@jayaddison
Copy link
Contributor Author

cc also @cjwatson; I'll admit that I had scanread the Debian bug yesterday, albeit without looking at your patch in any detail; I wrote this suggestion separately today after investigating and understanding the bug, and.. it's near-identical. I'm happy to defer to yours instead if you'd prefer (you wrote it first, and strictly speaking I had read the bug thread).

@jayaddison
Copy link
Contributor Author

(NB: I only compared the content of the patches after developing and testing this one.. difficult to prove that, though, I suppose)

@cjwatson
Copy link

cjwatson commented Jan 8, 2025

I have no sense of proprietary ownership here, and the fix seemed fairly obvious after understanding the problem. Go ahead.

@jayaddison
Copy link
Contributor Author

Thank you. Despite that, I'd recommend some caution from the maintainers before/if merging this; I think people without context could reasonably be skeptical that I authored it, and perhaps even if I think I did, I may have subconsciously picked up the details yesterday since it's a small patch.

@cjwatson
Copy link

cjwatson commented Jan 8, 2025

It doesn't worry me, but if you want to, you could include something like Co-authored-by: Colin Watson <[email protected]> in your commit message and that should remove any doubt.

@jayaddison
Copy link
Contributor Author

Possibly; in this context I'm currently skeptical about whether co-authorship is an accurate assessment. I think you authored the patch first, and then I apparently authored an equivalent patch independently (but as noted, I treat myself as an unreliable narrator).

@cjwatson
Copy link

cjwatson commented Jan 9, 2025

I really don't mind, and while I appreciate your diligence, with all due respect I think you're probably overthinking this. This patch is straightforward enough, and the new fixture is clearly similar enough to the existing source_date_year fixture, that independent invention is entirely plausible. And even if you did subconsciously copy it, I don't think it's worth my time to resubmit my marginally-different version of the PR separately.

@cjwatson
Copy link

cjwatson commented Jan 9, 2025

Also, the main reason I hadn't submitted it myself is that I hadn't got round to writing up my reasoning in a form suitable for a PR description. You did that in a way that's probably clearer than I would have done.

Comment on lines +12 to +16
@pytest.fixture
def source_date_empty(monkeypatch):
with monkeypatch.context() as m:
m.delenv('SOURCE_DATE_EPOCH', raising=False)
yield
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we only use this once, is it worth being a standalone function?

If we should keep it, could we add a docstring to describe why and when we should use the fixture?

A

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I experimented with this, I initially tried inlining it into the relevant test, but that didn't work since the monkeypatch needs to be applied before the app fixture is started.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

test_html_multi_line_copyright fails when SOURCE_DATE_EPOCH is set for 2024
3 participants