comprehensive-rust icon indicating copy to clipboard operation
comprehensive-rust copied to clipboard

Local `dprint` and `dprint` in CI want opposite things

Open djmitche opened this issue 1 year ago • 4 comments

locally, after installing the latest dprint and clearing ~/.cache/dprint,

from /usr/local/google/home/djmitche/p/comprehensive-rust/po/pl.po:
26052 26052| #~·"········let·Some(request_segment)·=·request_segments.next()·else·{\n"
26053 26053| #~·"············return·false;\n"
26054 26054| #~·"········};\n"
      26055|-#~·"········if·request_segment·!=·prefix_segment·&&·prefix_segment·!=·"
      26056|-#~·"\"*\"·{\n"
26055      |+#~·"········if·request_segment·!=·prefix_segment·&&·prefix_segment·!=·\"*\"·"
26056      |+#~·"{\n"
26057 26057| #~·"············return·false;\n"
26058 26058| #~·"········}\n"
26059 26059| #~·"····}\n"

but fixing that in CI leads to

from /home/runner/work/comprehensive-rust/comprehensive-rust/po/pl.po:
26052 26052| #~·"········let·Some(request_segment)·=·request_segments.next()·else·{\n"
26053 26053| #~·"············return·false;\n"
26054 26054| #~·"········};\n"
      26055|-#~·"········if·request_segment·!=·prefix_segment·&&·prefix_segment·!=·\"*\"·"
      26056|-#~·"{\n"
26055      |+#~·"········if·request_segment·!=·prefix_segment·&&·prefix_segment·!=·"
[26](https://github.com/google/comprehensive-rust/actions/runs/9663627985/job/26656256816?pr=2166#step:5:29)056      |+#~·"\"*\"·{\n"
26057 26057| #~·"············return·false;\n"
26058 26058| #~·"········}\n"
26059 26059| #~·"····}\n"

(I'll save you squinting at those -- they are opposite diffs)

I presume this is due to different msgcat versions?

⸩ msgcat --version
msgcat (GNU gettext-tools) 0.21

Is anyone else seeing this? How can we make this stable? I have a dprint check pre-commit hook, but as it stands I always have to use --no-verify because it always fails.

djmitche avatar Jun 25 '24 13:06 djmitche

Yes, someone else is seeing it :)

Shoudl we maybe disable formatting for .po files until this can be sorted out?

djmitche avatar Jul 05 '24 14:07 djmitche

I'm seeing this too... Looking at a recent CI log, I see that we're using gettext version 0.21-4ubuntu4 on the GitHub runners. The changelog shows lots of packaging changes between that version and the version -14 I get locally. Packaging changes should not affect the functionality, but I guess there could be a formatting change in a dependency.

One way of fixing this would be to write a dprint plugin which does the formatting for us — in Rust! I just happen to be the author of the textwrap crate, so I'm inclined to suggest that approach :smile:

A simpler approach would be to tell people more specifically which version of msgcat to install — if that is really is the problem.

mgeisler avatar Sep 24 '24 12:09 mgeisler

textwrap sounds like a good suggestion, and more hermetic than relying on msgcat versions. Since msgcat is usually installed system-wide, requiring a very specific version of it will cause challenges for contributors. If we choose that course we should, at the very least, check the version and error out if it is not correct.

djmitche avatar Sep 24 '24 14:09 djmitche

From #2166, it looks like using the same msgcat version is not enough.

djmitche avatar Oct 03 '24 22:10 djmitche