protocolbuffers/txtpbfmt

txtpbfmt parses, edits and formats text proto files in a way that preserves comments.

txtpbfmt's Issues

Ability to run in checking mode

It would be nice to be able to run textpbfmt on files in CI to check that they're properly formatted. google-java-format exposes this use-case through two options for example:

  --dry-run, -n
    Prints the paths of the files whose contents would change if the formatter were run normally.
  --set-exit-if-changed
    Return exit code 1 if there are any formatting changes.

undefined: math.MaxInt

I got the error below when running go get -u github.com/protocolbuffers/txtpbfmt/cmd/txtpbfmt

github.com/protocolbuffers/txtpbfmt/parser

parser/parser.go:1346:12: undefined: math.MaxInt

Support bracket notation for repeated messages "[{}]"

Support bracket notation for repeated messages "[{}]".

Example:

$ echo "value: [{}]" | fmt

parser.Format for path <stdin> with content "value: [{}]\n" returned err 

[{}] notation not supported

Full error: parser failed to make progress at index 8
position {Byte:8 Line:1 Column:9}
before: "value: ["
after: "{}]"
before+after: "value: [{}]"

1 error(s) encountered during execution

Please remove the hard dependency on glog

The parser imports https://github.com/golang/glog directly, for calls such as:

txtpbfmt/parser/parser.go

Line 392 in fc78c76

log.Errorf("format should be %s=<int>, got: %s", name, mc)

txtpbfmt/parser/parser.go

Line 989 in fc78c76

p.log.Infof("inlineComment: %q", strings.Join(inlineComment, "\n"))

It's understandable to want to have some verbose logging, but I think it's a bad idea for a "pure" Go library such as a parser to make direct calls to a logging library:

• It forces all importers to also include glog as part of their build and binary, even if they don't want nor need any logging.
• Logging shouldn't be enabled by default in generic libraries. The caller or main program should be in charge of logging, just like any input/output with the user.
• Hard-coding a logging library makes it very hard or near impossible to use a single log implementation across an entire program using multiple library packages.

I think the best and simplest API fix would be to declare a logging interface and use it, such as:

type Logger interface {
    Infof(format string, args ...interface{}) // used for verbose logs
    Errorf(format string, args ...interface{})
}

One could also argue that error logs should be returned as error values instead, but I'm not very familiar with how the glog API is designed in detail.

I'm filing this because I'm the maintainer of a relatively large open source program where we use and ipmort txtpbfmt, but we pull glog indirectly too, which unfortunately affects us in multiple ways (e.g. cue-lang/cue#1199, but also binary size etc).