Tokio-less APIs?

[RaitoBezarius]

Hi there, thank you for the amazing package :)

I am trying to use it in a project where I would like to have a std::process::Command-like API without any tokio/async/await stuff, do you think it is possible? I can also send a PR if you tell me what would you accept as a change regarding this.

Thank you!

[ysndr]

Thank you!

Our usecase is very much async focused so all the command stuff is very async centric and non async ways are currently not easily exposed.
Though Async stops after the Run trait and its impls.

It should be possible to define a RunSync trait and corresponding impl of a sync CommandLine backend, i.e. a sync version of

runix/crates/runix/src/command_line/mod.rs

Lines 216 to 255 in 3112401

	async fn run_command<M: CommandMode, A, B: NixCliCommand<Own = A>>(
	&self,
	command: &B,
	nix_args: &NixArgs,
	json: bool,
	) -> Result<M::Output, M::Error> {
	let args = vec![
	// apply default args always applicable
	self.defaults.config_args.to_args(),
	self.defaults.common_args.to_args(),
	nix_args.to_args(),
	B::SUBCOMMAND.iter().map(ToString::to_string).collect(),
	// apply command specific defaults if applicable
	// as defined by the command impl
	B::EVAL_ARGS
	.map(|_| self.defaults.eval_args.to_args())
	.unwrap_or_default(),
	B::FLAKE_ARGS
	.map(|_| self.defaults.flake_args.to_args())
	.unwrap_or_default(),
	if json {
	vec!["--json".to_string()]
	} else {
	vec![]
	},
	command.args(),
	self.defaults.extra_args.clone(),
	];
	let mut command = Command::new(self.nix_bin.as_deref().unwrap_or("nix"));
	command
	.envs(&self.defaults.environment)
	.args(args.into_iter().flatten());
	if let Some(ref cwd) = nix_args.cwd {
	command.current_dir(cwd);
	}
	M::run(&mut command).await
	}

If we go down that path both async and sync impls should share as much code as possible, so they do not become a maintenance burden

[RaitoBezarius]

Would you think it would make sense to gate sync APIs behind a feature and make it non default to reduce more the maintenance burden? Le jeu. 9 mars 2023 à 17:57, Yannik Sander ***@***.***> a écrit :

…

Thank you! Our usecase is very much async focused so all the command stuff is very async centric and non async ways are currently not easily exposed. Though Async stops after the Run trait and its impls. It should be possible to define a RunSync trait and corresponding impl of a sync CommandLine backend, i.e. a sync version of https://github.com/flox/runix/blob/3112401dc888111b7a074cbf4a52ebb2cd51e45b/crates/runix/src/command_line/mod.rs#L216-L255 If we go down that path both async and sync impls should share as much code as possible, so they do not become a maintenance burden — Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACMZRE7DBANJEIGZTWVTBDW3IDXRANCNFSM6AAAAAAVVBFHIM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ysndr]

Putting it behind feature flags in either direction would make sense.
Either way, we should look to share everything but the lines that are related to async commands.

runix/crates/runix/src/command_line/mod.rs

Lines 245 to 254 in 3112401

	let mut command = Command::new(self.nix_bin.as_deref().unwrap_or("nix"));
	command
	.envs(&self.defaults.environment)
	.args(args.into_iter().flatten());
	if let Some(ref cwd) = nix_args.cwd {
	command.current_dir(cwd);
	}
	M::run(&mut command).await

n.b. its able to "downgrade" a tokio command to an std command, perhaps its possible to go the other way around as well. than it should be a fairly minimal difference.