Sphinx: copyright substitution and reproducibility

[James Addison]

Thanks Chris - some responses inline below:

On Wed, 10 Jul 2024 at 13:08, Chris Lamb <chris at reproducible-builds.org> wrote:
> [ ... snip ... ]
> a) In https://github.com/sphinx-doc/sphinx/issues/12449 you ultimately
>    reject widening the match if a project uses an ASCII dash ("-").
>    Although it would take a bit of digging to find them at this point,
>    I'm sure I have seen projects using both en- and em-dashes in their
>    copyright lines purely for aesthetic reasons, and rather than as a
>    way to circumvent automatic replacement. It would be a shame if a
>    single project is preventing packages using those kinds of dashes
>    from becoming reproducible, especially as there may be better, and
>    more reliable, solutions for projects wishing to opt out entirely.
>
> b) Similar to (a), I have analogous experiences re. many projects using
>   "PREV - YYYY" style spacing, which from a quick glance the code does
>   not currently detect. It seems sensible to also catch these. I don't
>   know of any projects using this format variant as a way of opting out
>   too, lending strength to its inclusion.

Could you elaborate on the other possible reliable solutions?

I've heard that some technology companies have stopped adding years to their
copyright notices at all, a practice that in some ways seems logical, but I
tend to think that smaller entities / individuals might be reluctant to do that
given that they have fewer resources and might want to rely on more clearerly
published statements as a result.

> c) You reject parsing the conf.py source file in order to alter the
>    AST prior to evaluation. I would second avoiding that. :)

Thanks - yep, even parsing seems non-ideal, so modification is even less so.

> d) Roughly following on from (c): was monkey-patching
>    datetime.datetime.{now,utcnow,today} etc. ever seriously considered
>    as an option by the Sphinx project? If it was limited strictly to
>    the evaluation of conf.py, it could be quite effective and have
>    limited side-effects. Mostly just curious, as I'm not sure I could
>    fully endorse this approach…

This is a good question - I don't know.  My sense would be that it could risk
affecting other imported code components (Sphinx extensions, for example)
in unexpected ways, even at a config-only scope.  I'll try to ask about this
upstream at an opportune time.

Thanks again,
James