Skip to content

Conversation

@cacama-valvata
Copy link

Opening a premature PR on this so that I can get midway feedback and get most of my "TODO" questions answered this Sunday (not all of the TODOs are for y'all but most of them are, feel free to comment on any you want to give insight on). Please add your answers to the TODOs via comments in a review on this PR since I can't be there this Sunday

@cacama-valvata
Copy link
Author

clarification: i do not care about code formatting feedback, such as the compiler warnings for the structs or the cargo fmt fails. I will deal with those after all implementation is done.

Copy link
Contributor

@detjensrobert detjensrobert left a comment

Choose a reason for hiding this comment

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

Structure comments:

  • So far, I've tried to keep the bulk of the logic for comands in their own folders, and run() orchestrates which thing to call based on the command line flags (i.e. build::run() calls build_image() and then push_images() if --push was given). I think the *_init() functions and the struct definitions should go in their own folder/file to follow this. Thoughts from the rest of the team?

@cacama-valvata
Copy link
Author

Structure comments:

* So far, I've tried to keep the bulk of the logic for comands in their own folders, and `run()` orchestrates which thing to call based on the command line flags (i.e. `build::run()` calls build_image() and then push_images() if `--push` was given). I think the `*_init()` functions and the struct definitions should go in their own folder/file to follow this. Thoughts from the rest of the team?

done

@cacama-valvata
Copy link
Author

Since this PR is so out of date with the main branch, I have moved all of these changes to branch af/init-command2. Once that other branch is merged in, I will close this PR.

@detjensrobert detjensrobert changed the title af/init command Challenge repo init command Sep 27, 2025
@detjensrobert detjensrobert force-pushed the af/init-command branch 2 times, most recently from 2510f36 to bdfd2bd Compare September 27, 2025 19:49
Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
We already have an existing struct used to parse the rcds.yaml config,
use that to build the example/interactive config instead of creating
an almost-identical struct.

So far this is only done for the example values / non-interactive init.

Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
Having this be a string is more user friendly than a number, and this
branch was originally set up to do that.

Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
Blank and placeholder template files should be set explicitly by the user.

Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
serde_yml turns out to be maintained weirdly (issues disabled, weird refactors)
and is now archived anyway. _ng is what the community is now recommending.

Signed-off-by: Robert Detjens <github@detjens.dev>
@detjensrobert
Copy link
Contributor

This is now ready for review again, spruced up and tested.

@detjensrobert detjensrobert requested a review from a team December 11, 2025 04:24
Comment on lines +24 to +31
// FORMATTING NOTE: Some of these help messages cause rustfmt to silently
// fail to format this struct definition. Commenting out the marked
// help_message lines temporarily will let the formatting work.
//
// Ref:
// - https://github.com/rust-lang/rustfmt/issues/6687
// - https://github.com/rust-lang/rustfmt/issues/3863
Copy link
Contributor

@detjensrobert detjensrobert Dec 11, 2025

Choose a reason for hiding this comment

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

Rustfmt currently has some issues with formatting this file due to line length limitations. The issues linked here have more context (rust-lang/rustfmt#6687, rust-lang/rustfmt#3863) -- TLDR rustfmt silently fails on really long lines/method chains and thus fails to format this file unless the lines marked with // too long to format are commented out.

@cacama-valvata and I discussed offline a while ago about this and he recommended that this is is documented in the Discord rather than a code comment here since this seems unprofessional. I disagree with that point and prefer to have it documented here so that it cannot get lost or forgotten and have to figure this all out again in the future, because this is a bug in rustfmt and not (personally) a code smell.

Do any of the rest of you have thoughts on if this should be documented and where?

Copy link
Contributor

Choose a reason for hiding this comment

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

TIL this is a problem. I wonder how often it's happened to me and I never noticed before?

I tried format_strings with the nightly toolchain and it doesn't help here. I don't think it's worth breaking the strings manually, either. I think the status quo is fine even if the too long to format comments aren't necessary.

Comment on lines +62 to +65
.with_help_message(
"The username that the cluster will use to pull locally-built containers.",
)
Copy link
Contributor

Choose a reason for hiding this comment

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

I would personally just use a regex to comment these all out at once so I could format. This is the only help message that's not contained on a single line. Not a big deal to change it manually and do that.

Copy link
Contributor

@detjensrobert detjensrobert left a comment

Choose a reason for hiding this comment

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

Also a note: the placeholder/blank config structs could be done via the Default trait on the object, but only one of them can so I have not done that. Should one of them be the Default, and if so which?

Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
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.

4 participants