-
Notifications
You must be signed in to change notification settings - Fork 289
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Add --stdin flag to 'buf format' #1345
Conversation
|
||
stdin = bytes.NewBuffer( | ||
[]byte(` | ||
syntax = "proto3"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add a test for multiple files concat'ed together, and either expect success or expect error? If error, document that --stdin
can only take one file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait on second thought - should this not be buf format -
to be consistent, since -
for inputs represents stdin? Or am I getting confused? This might be a special case, but wanted to check before we merge.
Nah it's good that you called this out - I'll explain my original reasoning upfront, then we can decide if we want to change this (we probably do). Use
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This works but it would be nice to support process substitution and other inputs that cannot seek.
if flags.Stdin { | ||
// We need to read the raw bytes from the io.Reader upfront so that | ||
// the content can be referenced more than once: once by the formatter, | ||
// and again during the diff. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I smell something here. --stdin
is implemented with a divergent different code path because its input is a non-seekable file. Standard input is not the only non-seekable file out there: sockets, tape-archive on literal tape, named pipes, bash's named descriptors (/dev/fd/), etc.
One alternative is to implement a buffered, seeking reader. Wrap stdin with your reader and no more special code paths, I hope. I haven't groked all of the format package yet and run
is particularly hard to follow.
This concept can extend further if you open a file input and attempt to seek to offset 0. That should, on POSIX systems, fail on pipes, sockets, and other file handles that are non-seekable. Commands like buf format <(cat foo.proto bar.proto)
become possible.
Sadface :( Looks like this PR isn't going to get merged, but is #1035 still planned? |
We have no near-term plans on this as there's some thinking we need to do on it, but we may get to it in a few months. We'll keep the issue open for now, we just need the time to budget to make sure we get this right. |
Fixes #1035
This adds a
--stdin
flag tobuf format
so that users can format the.proto
content read fromstdin
, rather than requiring a file on disk. This makes it far easier to write developer tools that would otherwise need to create a temporary file containing the buffer's content (re: #1334 (comment)).Unsurprisingly, the
--output
and--write
flags are not supported alongside--stdin
. For anyone that needs to write the formatted content to disk, they can simply redirect the formatted result written tostdout
.