@Wyverald FYI

+1 to getting this landed

@vladmos

@vladmos Would it be possible to get this released so that Bazel can start depending on this behavior?

@fmeum This change causes some failures internally and may need to be reverted. The feedback I got:

This change seems on the surface desirable as it corrects the flaw that without the "modified:" argument, the consumer could not distinguish RETURN_CODE_OK_NO_CHANGES from RETURN_CODE_OK. (It was getting "NO_CHANGES" no matter what). Unfortunately it causes problems with Python API users that have "out, err = buildozer.Buildozer().invoke()" because the secondary value is now the non-empty contents of stderr which is treated as a success/fail indicator (empty string = good).

Do you have any reasonable changes in mind that would both satisfy your needs and are not breaking at the same point? Or at least easy to fix on the consumer side (without actually parsing stderr)?

It does seem wrong to me to treat stderr != "" as indicating an error. Would consumers be able to check the exit code somehow? Is the buildozer Python API public?

@fmeum @vladmos This seems to still blocking the progress of bazelbuild/bazel#25540?

@oreflow in case you could help