Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(runtime): two-tier subprocess API #11618

Merged
merged 93 commits into from
Apr 20, 2022
Merged

Conversation

crowlKats
Copy link
Member

@crowlKats crowlKats commented Aug 9, 2021

Fixes #11016

Left to do:

  • documentation
  • tests

Things ideally to have before landing:

@crowlKats
Copy link
Member Author

crowlKats commented Aug 9, 2021

My concerns with this API is that this has too much API surface and has multiple ways to do the same thing:
await new Command().status() and await new Command().spawn().wait()
await new Command().output() and await new Command().spawn().output()
making the Command methods superfluous except spawn(), which doesn't make much sense and could be "collapsed"/simplified to just Child, so don't see that much need for 2-tier subprocess

runtime/ops/command.rs Outdated Show resolved Hide resolved
@bartlomieju bartlomieju added this to the 1.14.0 milestone Aug 11, 2021
@crowlKats
Copy link
Member Author

On top of previous concerns, do we really need both status() and output() if output() includes status()?

@bartlomieju
Copy link
Member

My concerns with this API is that this has too much API surface and has multiple ways to do the same thing:
await new Command().status() and await new Command().spawn().wait()
await new Command().output() and await new Command().spawn().output()
making the Command methods superfluous except spawn(), which doesn't make much sense and could be "collapsed"/simplified to just Child, so don't see that much need for 2-tier subprocess

That's on purpose to mimic Rust's API. There's a difference between those APIs - eg. if you use await new Command().output() we should automatically make sure that stdout and stderr are set to piped.

On top of previous concerns, do we really need both status() and output() if output() includes status()?

Yes, there are situation where you might not want to collect output from the command - either discard it setting the pipes to null or use inherit.

Again - the idea was to mimic Rust's API which is very flexible yet it has a simple "happy path" that most of the users will use.

@crowlKats
Copy link
Member Author

crowlKats commented Aug 29, 2021

Yes, there are situation where you might not want to collect output from the command - either discard it setting the pipes to null or use inherit.

But output() takes care of that:

deno/runtime/ops/command.rs

Lines 171 to 183 in 046ae0c

Ok(CommandOutput {
status: output.status.into(),
stdout: if &stdout == "piped" {
Some(output.stdout.into())
} else {
None
},
stderr: if &stderr == "piped" {
Some(output.stderr.into())
} else {
None
},
})
as else it just returns an empty uint8array

@crowlKats
Copy link
Member Author

That's on purpose to mimic Rust's API. There's a difference between those APIs - eg. if you use await new Command().output() we should automatically make sure that stdout and stderr are set to piped.

Then it would rather make sense to move stdin, stderr, and stdout options from the main constructor to what currently is the spawn() method

cli/dts/lib.deno.unstable.d.ts Outdated Show resolved Hide resolved
runtime/js/40_command.js Outdated Show resolved Hide resolved
runtime/js/40_command.js Outdated Show resolved Hide resolved
runtime/js/40_command.js Outdated Show resolved Hide resolved
runtime/js/40_command.js Outdated Show resolved Hide resolved
runtime/js/40_command.js Outdated Show resolved Hide resolved
runtime/js/40_command.js Outdated Show resolved Hide resolved
runtime/ops/command.rs Outdated Show resolved Hide resolved
@bartlomieju bartlomieju mentioned this pull request Sep 1, 2021
23 tasks
@bartlomieju bartlomieju removed this from the 1.14.0 milestone Sep 1, 2021
Copy link
Member

@lucacasonato lucacasonato left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ops are not marked as unstable.

@crowlKats
Copy link
Member Author

@lucacasonato

super::check_unstable(state, "Deno.spawn");

cli/diagnostics.rs Outdated Show resolved Hide resolved
Copy link
Member

@lucacasonato lucacasonato left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI is failing on linting, but other than that LGTM!

Thanks for seeing this through @crowlKats! Very exciting to have this finally done. 🎉

Copy link
Member

@bartlomieju bartlomieju left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. You are most likely the winner in "the longest time to merge the PR" contest in Deno @crowlKats 🤣

@crowlKats
Copy link
Member Author

@bartlomieju and i think second place is webgpu, which took 7 months 🤣

@crowlKats crowlKats merged commit 8a7539c into denoland:main Apr 20, 2022
@crowlKats crowlKats deleted the command branch April 20, 2022 22:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement new two-tier subprocess API
9 participants