Skip to content

Don't wait on stdin by default for batch commands#680

Closed
HenrikPoulsen wants to merge 1 commit into
sourcegraph:mainfrom
HenrikPoulsen:default-file
Closed

Don't wait on stdin by default for batch commands#680
HenrikPoulsen wants to merge 1 commit into
sourcegraph:mainfrom
HenrikPoulsen:default-file

Conversation

@HenrikPoulsen

Copy link
Copy Markdown
Contributor

So I've been on a several month long goose chase.
I have been unable to create sourcegraph batches due to it hanging when running things like src batch preview in the folder that has a batch spec file.
It would hang forever on the message ⠋ Parsing batch spec
Maybe the issue is already obvious here, but I was in contact with Sourcegraph staff about this and did show them my invocation, and they also asked me to try some invocations with the same issue.

I tried this on windows, on wsl2, and even created a virtual box ubuntu vm, all had the same issue. Then finally I dusted off an old mac pro and tried it there, the same issue. So it obviously wasn't a hardware problem.
At that point I realized the cli is open source so I just tried to reproduce it with a debugger attached, and it was easily reproducible.

The problem is that it seems that src requires you to specify -f when you want to use a file, and it does not by default find the batch.yaml in the current folder.
Instead it defaults to reading from stdin and expects the batch file from there. This is not printed however so an end user is completely stumped as to what is going on.
The help text for the commands does not mention this either, so for the casual user it would not be obvious that you cannot ommit -f and instead are expected to add it or do something like cat batch.yaml | src batch preview.

This PR serves as one example how to solve this.

I set the default value to if -f is missing to be batch.yaml, which is what src batch new creates by default.
So to me it seems obvious that by default the batch commands looks for the file that is created when a new batch is created with the default name.

This is obviously a breaking change, but I cannot speak to how much of an issue this is. If you know that a lot of tooling exists that rely on this, then you likely would not want this approach.

Another approach would be to simply print "waiting for stdin" when stdin has been indicated, so the user is actually made aware that something is wrong here.

Personally I prefer to default to looking for batch.yaml for the reason mentioned above. But it's your tool so please do advise here. Thanks

@malomarrec

Copy link
Copy Markdown

Many thanks for submitting this thoughtful PR, and investing all that time. It makes a lot of sense, we will discuss it as a team, and post next steps here.

@chrispine

Copy link
Copy Markdown

Yes, I also wanted to thank you, @HenrikPoulsen, for your thoughtful PR, and to apologize for the headache this has caused you! We will get on this, and I hope you're now able to explore Batch Changes. Thanks!

@chrispine chrispine added the good first issue Good for newcomers label Jan 14, 2022
@eseliger

Copy link
Copy Markdown
Member

Hi @HenrikPoulsen 👋 Thank you for this thorough proposal for making Batch Changes more intuitive to use. We decided to accept this proposal and change the behavior and not wait for stdin to provide input. :)

We will likely do the following:

  • Do a quick detection for backcompat if on a tty and stdin provides input within a few ms
  • Allow -f - as other CLIs do to signify that stdin should be used instead of a filename
  • Otherwise always enforce -f to be set, instead of silently waiting for stdin

We will prioritize this in our next sprint planning on Tuesday.

LawnGnome added a commit that referenced this pull request Feb 1, 2022
@LawnGnome

Copy link
Copy Markdown
Contributor

Thanks for your PR, Henrik! We ended up doing something similar, but slightly different — we've altered src to error out if a file name isn't provided and a file isn't being piped in, and made the -f optional, but haven't hard coded a default file name into the flags. So, slightly different, but we think that still addresses the main issue.

This will be coming in the next src release, which I anticipate will be in the next week or so.

Thanks again!

@HenrikPoulsen

Copy link
Copy Markdown
Contributor Author

Sounds great. Thanks!

@HenrikPoulsen HenrikPoulsen deleted the default-file branch February 1, 2022 21:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants