FWIW just 1c: know that scriv is used, and breaking changes "brake things"

[yarikoptic]

As we started to use scriv more and established our "scriv-based" release workflow across datalad extensions , a failed release came as a surprise due to scriv.exceptions.ScrivException: No such file: templates/entry_title.md.j2 .

IMHO adding such new semantic while breaking existing workflows is suboptimal. If there was need to enable some new setups/relative paths, some new syntax, less likely to be used (e.g. paths started with ./ or special file:/// URI protocol specification) might have been better.

[nedbat]

Hi, I certainly don't intend to break things. I'm not sure what version you were using, and what version you upgraded to? What was your configuration? Can you provide more information so I can understand better? What is the full error report?

[yarikoptic]

Hi Ned. Sorry I was too brief - I was suffering from "I touched the damn laptop during the weekend for a quick 'Just to press this button to merge this PR' and then it sucked me in...". I will try to refrain from such actions in the future for both of our sake ;)

TL;DR: I think that the change in 1.1.0 — 2023-01-16 "File names specified for file: settings will be interpreted relative to the current directory if they have path components. If the file name has no slashes or backslashes, then the old behavior remains: the file will be found in the fragment directory, or as a built-in template." is the one which broke our workflows.

Our generalized setup across repos is to have changelog.d/ folder with

changelog.d
├── scriv.ini
└── templates
    ├── entry_title.md.j2
    └── new_fragment.md.j2

and which collects changelog snippets until then release workflow runs scriv (from top directory of the repo where CHANGELOG.md) to combine them all, see e.g. https://github.com/datalad/datalad/tree/maint/changelog.d . That scriv.ini contains:

❯ grep template changelog.d/scriv.ini
entry_title_template = file: templates/entry_title.md.j2
new_fragment_template = file: templates/new_fragment.md.j2

We use scriv within our release-action where it gets installed "fresh" from pypi - https://github.com/datalad/release-action/blob/9a00230a3d36b41964d580c818f02060892a20ec/release/action.yml#L35, so we used versions available at that point in time.

e.g. Jan 16th we got a release cooked, log is here and it had

 Downloading scriv-1.0.0-py2.py3-none-any.whl (29 kB)

and we got release produced. Yesterday workflow failed in datalad-container, full log with

  File "/home/runner/work/_actions/datalad/release-action/master/release/infra/lib/python3.11/site-packages/scriv/config.py", line 392, in read_file_value
    raise ScrivException(f"No such file: {file_path}")
scriv.exceptions.ScrivException: No such file: templates/entry_title.md.j2

and we had already

Collecting scriv
  Downloading scriv-1.2.0-py2.py3-none-any.whl (31 kB)

which supports my identification of culprit in TL;DR above identified from the CHANGELOG. I had to patch up our scriv.ini in datalad-container https://github.com/datalad/datalad-container/commit/6e20ac204bf06c77637d7211483662b6c3b895e2 to include changelog.d/ prefix . But now would need to do it in other repos as well I guess .

[nedbat]

OK, thanks. As of commit 530c9de25005b29ee308d50fbdffdf6fa6c16424, all file paths are looked for in the fragments directory, and then in the current directory, and then as a builtin template. UNLESS the first file path component is . or .., then it only looks in the current directory.

[nedbat]

This is now released as part of scriv 1.2.1.