You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While working with the known-merge resolver, when placeholders are in the README, the merge routine works fine to re-substitute the placeholders. But when the conflict is in the pyproject.toml, the routine is unable to load the project metadata because the syntax of that file is broken by the conflict.
And because of the way the merge tool works, the routine is only called after the conflict is already manifest, so there's no great hook point to extract the metadata before the conflict is manifest.
The text was updated successfully, but these errors were encountered:
jaraco
changed the title
Dang. So when these placeholders are in the README, the [merge routine](https://github.com/jaraco/jaraco.develop/blob/fdeed29219cb2e9104efa5535eb50f73c5b03a58/jaraco/develop/merge.py#L80-L91) works fine to re-substitute the placeholders. But when the conflict is in the pyproject.toml, the routine is unable to load the project metadata because the syntax of that file is broken by the conflict.
Unable to resolve placeholders in pyproject.toml
Jun 21, 2024
Oh. So I do see that git does provide a reference to the base, local, remote, and merge files, and the "local" copy is presumably the one with the placeholders applied before the patch. It's conceivable that one could copy that file to a temporary directory, build the metadata there, and use it to restore the placeholders.
While working with the known-merge resolver, when placeholders are in the README, the merge routine works fine to re-substitute the placeholders. But when the conflict is in the pyproject.toml, the routine is unable to load the project metadata because the syntax of that file is broken by the conflict.
And because of the way the merge tool works, the routine is only called after the conflict is already manifest, so there's no great hook point to extract the metadata before the conflict is manifest.
Originally posted by @jaraco in jaraco/skeleton#129 (comment)
The text was updated successfully, but these errors were encountered: