Consider adding native support for SOURCE_DATE_EPOCH to %Y copyright placeholder #13526
Replies: 3 comments 2 replies
-
Minor correction -- the Uncertainties case is regarding switching from en dash to hyphen, not em dash to hyphen. I mention this because the Wikipedia entry for en dash lists "to connect symmetric items, such as the two ends of a range" as the first use case. |
Beta Was this translation helpful? Give feedback.
-
If |
Beta Was this translation helpful? Give feedback.
-
I've opened a proposed changeset to provide native |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
In a recent bugthread at lmfit/uncertainties#312, a project is considering switching from a
copyright
config value that contains anem-dashen-dash to one that instead uses a simple ASCII hyphen -- in order to enable Sphinx's copyright substitution logic, that in turn supports reproducible builds.I had momentarily suggested that the project could instead begin using the
%Y
placeholder in theircopyright
confval -- a feature added in Sphinx v8.1.0 -- hoping that this change alone would solve their problems.However: I had forgotten that the
%Y
placeholder does not natively support theSOURCE_DATE_EPOCH
reproducible build timestamp environment variable.In other words: it's possible to use
%Y
in combination with the existing substitution logic -- but the limitations of the latter (e.g. em-dash will not pattern-match) continue to apply.I wonder whether we could/should enable
SOURCE_DATE_EPOCH
natively when string-replacing the%Y
value -- in preference to the system clock year that we currently use unconditionally -- when that env var is configured.Edit:
en-dash
, notem-dash
- thank you, @wshanks.Beta Was this translation helpful? Give feedback.
All reactions