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
port(turborepo): Run stub #4752
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
7 Ignored Deployments
|
@NicholasLYang is attempting to deploy a commit to the Vercel Team on Vercel. A member of the Team first needs to authorize it. |
c0e5924
to
5d9fd46
Compare
6bd91da
to
e1de259
Compare
e1de259
to
ec59ac9
Compare
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 is a great start, and I think is already highlighting some areas for improvement.
Let's do the renames, and maybe the task id bit, then merge.
Can you also add a stub test that just "executes" a run?
@@ -0,0 +1,10 @@ | |||
#[derive(Debug)] | |||
pub struct Manager { |
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.
Is this the child process manager? Can you add a comment?
}; | ||
|
||
#[derive(Debug)] | ||
pub struct Opts<'a> { |
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.
Do we care about the opts having a lifetime? Would it make it easier if they owned their data? It's not a ton of data...
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.
Right now it can go either way. I think in the future I'd like a single 'run
lifetime that's tied to either CommandBase
or a Run
struct. And that can own stuff like Args that then in turn get transformed to Opts
. For now I don't think we have to make that call until this is used.
|
||
use crate::{package_json::PackageJson, run::graph::WorkspaceCatalog}; | ||
|
||
pub struct Context { |
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 name this PackageGraph
? Or something like that? The Context
name from Go is not great.
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.
Yeah definitely. Context
is very confusing imo
} | ||
} | ||
|
||
#[derive(Default)] |
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.
Here, and elsewhere, I'm assuming we intend to remove the Default
derivations in the future?
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.
yeah definitely. Mostly for boilerplate
crates/turborepo-lib/src/run/mod.rs
Outdated
} | ||
|
||
impl<'a> Run<'a> { | ||
pub fn new(base: &'a CommandBase, opts: Opts<'a>) -> Self { |
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.
Would it make more sense for the Run
to own the CommandBase
? Do we continue using it after executing a command?
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've thought about having all the commands be methods of CommandBase, that way we can have all of the relevant resources be owned by CommandBase
pub type Pipeline = HashMap<String, BookkeepingTaskDefinition>; | ||
|
||
#[derive(Debug, Default, Serialize, Deserialize)] | ||
pub struct BookkeepingTaskDefinition { |
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.
cc @mehulkar
Is there a path to dropping the Bookkeeping
in a rust world? Post-port? Or something we can do as part of the porting effort?
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.
It's main goal was to assist in merging fields. If Rust has a better way to distinguish between when a field is missing vs when it's the "empty value", we should be able to drop it. The integration tests covering this behavior are pretty good, so I'd just say "try it"
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.
Yep! We can do Option<T>
for those
pub const TASK_DELIMITER: &str = "#"; | ||
pub const ROOT_PKG_NAME: &str = "//"; | ||
|
||
pub fn get_task_id(pkg_name: impl std::fmt::Display, target: &str) -> String { |
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'm 99% certain that task id doesn't need to be a string. Can we try a simple struct?
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.
What do you mean by simple struct here?
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.
Thought about this a bit, and I think "simple" might not be the right word. And we maybe shouldn't block on this. I'm thinking of something like:
pub enum TaskId {
SinglePackage { task: String },
Monorepo {
package: Option<String>,
task: String
}
}
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 is a great start, and I think is already highlighting some areas for improvement.
Let's do the renames, and maybe the task id bit, then merge.
Can you also add a stub test that just "executes" a run?
}; | ||
|
||
#[tokio::test] | ||
async fn test_run() -> Result<()> { |
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 is not an integration test because I'd need some way to plumb rust features through integration tests.
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 you add a comment re: Manager
and then let's merge + iterate
Merged as #5099 |
Description
This is more a proof of concept than an actual implementation. Attempts to write the beginning of run in what's hopefully semi-idiomatic Rust, with all of the helper functions stubbed out.
Testing Instructions
The stub is gated behind a rust feature flag
run-stub
, so to test the code add--features run-stub
to your cargo command