Feat: Concurrent manifest execution #556
Conversation
app/src/utils/dependency_graph.rs
Outdated
| if should_ask_for_pass { | ||
| let mut password_manager = | ||
| PasswordManager::new(get_privilege_provider(contexts).as_deref())?; | ||
| password_manager.prompt("Please enter password:").await?; |
There was a problem hiding this comment.
This is a problem since the implementation in password_manager.rs is for linux only. Is this due to just testing and development on linux or can this functionality not work on windows/macOS/BSD(s)?
There was a problem hiding this comment.
Due to testing on linux only. I'll need to first get linux working then I can work on windows/macOS/BSD. I just don't know how I'm gonna get it to stop asking for password while running elevated commands.
| String::from("--noconfirm"), | ||
| String::from("--noprogressbar"), | ||
| String::from("--skipreview"), | ||
| String::from("--sudoloop"), |
There was a problem hiding this comment.
So the issue with it asking for password during any package manager operations even though I'm using the PasswordManager is here. Both Paru and Yay use sudo under the hood and since sudo defaults to /dev/tty, it's overriding the piped stdin in exec.
That said the only fix I have been able to come up with (that's worked so far) is this:
...
atom: Box::new(Exec {
command: String::from("echo"),
arguments: [
command: String::from(secret),
command: String::from("|"),
command: String::from("paru"),
...I tried immediately writing the secret in exec instead of echoing like this but for some reason sudo isn't picking it up.
This may need similar workarounds for other package managers unless someone can come up with a better way of doing this
45e504f to
decdbf2
Compare
Just need to get elevations working correctly and clean things up
reverted to original dependency lookups & corrected dependency waiting
c3deb1c to
2884eeb
Compare
|
Pulled the branch to run it. With just some initial running, I came across this being spit out in the comtrya output. This looks like it may be a good reference. This occurs when running |
lib/Cargo.toml
Outdated
| file-owner = "0.1.2" | ||
| gix = { version = "0.68.0", features = ["blocking-http-transport-reqwest-rust-tls", "blocking-network-client"] } | ||
| gix = { version = "0.68.0", features = [ | ||
| "blocking-http-transport-reqwest-rust-tls", |
There was a problem hiding this comment.
Pulled the branch to run it. With just some initial running, I came across this being spit out in the comtrya output.
Just saw this, without testing; it's likely just because of the use of blocking calls from the main branch, I didn't test file downloads or git clones when I was developing. They weren't on my radar. Looks like here and above a couple lines in reqwest both use the blocking protocol and that won't work with async. Probably just changing these will fix it, I'll take a look and correct when I get a chance.
There was a problem hiding this comment.
gix works with async_std not regular async
I'm submitting a
What is the current behavior?
Comtrya currently executes manifests sequentially, running each one in order of their dependencies. This leads to slower execution times when manifests could safely run concurrently.
What is the expected behavior?
Manifests should execute concurrently when they have no dependents.
What is the motivation / use case for changing the behavior?
Faster manifest execution using concurrent processing where possible.
Details:
Known Issues / TODO:
Please tell us about your environment:
Version (comtrya --version): v0.9.1
Operating system: CachyOS