Skip to content

Conversation

@gomnitrix
Copy link
Contributor

Summary

Replaces rename-project.sh with a native rust implementation (cargo xtask bootstrap), supporting both CLI arguments and interactive mode.

Usage

CLI mode:

cargo xtask bootstrap --project-name my-project --github-account my-username

Interactive mode:

cargo xtask bootstrap

@gomnitrix
Copy link
Contributor Author

@tisonkun
Sorry for the delay, I've been quite busy lately and just got around to finishing this migration. Would appreciate your review when you have time. Thanks!
Btw, I'm still learning Rust best practices, so please don't hesitate to suggest any improvements to naming, structure, or any other aspects of the code. I'll be happy to make changes.

@gomnitrix gomnitrix force-pushed the dev-subcmd-bootstrap branch from 8c41a91 to 191eec0 Compare December 17, 2025 02:12
Comment on lines +26 to +32
mod colors {
pub const RED: &str = "\x1b[31m";
pub const GREEN: &str = "\x1b[32m";
pub const YELLOW: &str = "\x1b[33m";
pub const BLUE: &str = "\x1b[34m";
pub const RESET: &str = "\x1b[0m";
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Rust ecosystem has a colored crate for generating colored string. You can add it to xtask's dependency and make use of it.

Copy link
Contributor

Choose a reason for hiding this comment

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

dialoguer recommends https://github.com/console-rs/console. I don't distinguish them too much. You can read them by yourself and make the decision.

Comment on lines +279 to +281
if !Path::new("Cargo.toml").exists() || !Path::new("xtask").is_dir() {
return Err("This command must be run from the project root directory".into());
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I suppose we can resolve the path with a technique like:

Then we don't need this assumption.

Comment on lines +291 to +297
fn prompt_input(prompt: &str) -> String {
print!("{}: ", prompt);
stdout().flush().unwrap();
let mut input = String::new();
stdin().read_line(&mut input).unwrap();
input.trim().to_owned()
}
Copy link
Contributor

Choose a reason for hiding this comment

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

For prompt interaction, you can make use of https://github.com/console-rs/dialoguer. It should simplify many code here.

Copy link
Contributor

@tisonkun tisonkun left a comment

Choose a reason for hiding this comment

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

Thanks for your contribution! Comments inline. I think many existing crates can help here.

Also, after bootstrap, the related code should be able to be deleted safely (they are useless now anyway). So I suggest either move the code to a standalone file for easy deletion, or the command itself can detect if the bootstrap is finished, then delete all the related code from itself.

@tisonkun
Copy link
Contributor

@tisonkun Sorry for the delay, I've been quite busy lately and just got around to finishing this migration. Would appreciate your review when you have time. Thanks! Btw, I'm still learning Rust best practices, so please don't hesitate to suggest any improvements to naming, structure, or any other aspects of the code. I'll be happy to make changes.

Never mind. Enjoy your days :D

Comments above and thanks a lot for spending your time on contribution!

@gomnitrix
Copy link
Contributor Author

gomnitrix commented Dec 18, 2025

Thanks for your contribution! Comments inline. I think many existing crates can help here.

Also, after bootstrap, the related code should be able to be deleted safely (they are useless now anyway). So I suggest either move the code to a standalone file for easy deletion, or the command itself can detect if the bootstrap is finished, then delete all the related code from itself.

@tisonkun Thanks for the suggestions, I initially hesitated to add dependencies for this subcommand, but you're right, those crates would be very helpful!

Regarding cleanup: I prefer moving all bootstrap-related code to a standalone file (e.g., bootstrap.rs) for easy deletion. However, I'm uncertain about the deletion strategy. currently I have two approaches in mind:

  1. Simple approach: Leave deletion to the user. After bootstrap completes, remind user to delete the bootstrap file once they verify everything works correctly, and provide appropriate messages on subsequent command invocations.
  2. Robust approach: Implement transactional behavior, rollback to the pre-execution state on any error with helpful guidance for retry. Once the command successfully complete, automatically delete the bootstrap file and show appropriate messages for subsequent invocations.

which one makes more sense to you? or is there any better way to handle this? Happy to hear your thoughs :)

@tisonkun
Copy link
Contributor

tisonkun commented Dec 19, 2025

@gomnitrix I think we can first leave the deletion to the user. Just keep all the bootstrap setup/code as gathered as possible. So users would be easy to delete by themselves.

Later we can figure out whether it's possible to delete automatically. Typically, automation is doing something you will do manually by the machine :D

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.

2 participants