Skip to content
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

Add confirm prompt #1834

Merged
merged 36 commits into from
Jan 13, 2024
Merged

Add confirm prompt #1834

merged 36 commits into from
Jan 13, 2024

Conversation

CramBL
Copy link
Contributor

@CramBL CramBL commented Jan 10, 2024

Add functionality to allow specifying a prompt for the confirm recipe attribute.

e.g. [confirm("this recipe is dangerous because blabla")]

It's a quick and dirty implementation, feel free to nitpick. And thanks a lot for your great work!

Copy link
Owner

@casey casey left a comment

Choose a reason for hiding this comment

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

Looks great! Check out the review comments. If you feel like it, also take a crack at documenting this in the readme.

src/attribute.rs Outdated Show resolved Hide resolved
src/compile_error.rs Outdated Show resolved Hide resolved
tests/confirm.rs Outdated Show resolved Hide resolved
src/recipe.rs Outdated Show resolved Hide resolved
src/recipe.rs Outdated Show resolved Hide resolved
@CramBL
Copy link
Contributor Author

CramBL commented Jan 11, 2024

Looks great! Check out the review comments. If you feel like it, also take a crack at documenting this in the readme.

I will document it in the README.md later today (I expect)

EDIT: Done.

Copy link
Owner

@casey casey left a comment

Choose a reason for hiding this comment

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

Nice, looks good, check out my review comments.

README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
src/parser.rs Outdated Show resolved Hide resolved
src/attribute.rs Outdated Show resolved Hide resolved
src/parser.rs Outdated
let arguments = if self.accepted(ParenL)? {
let mut arguments = Vec::new();

while self.next_is(StringToken) {
Copy link
Owner

Choose a reason for hiding this comment

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

Actually, we only have one attribute that accepts a string literal, and if we're accepting multiple arguments, we would want to accept commas between them, so we can make arguments be an Option.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Comma-separated arguments are now accepted, do should comma+space also be accepted?

Copy link
Owner

Choose a reason for hiding this comment

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

Ah, no sorry, what I was getting at is that we don't have any multi-argument attributes, so we shouldn't bother either with parsing multiple arguments, with or without commas. We can just parse ( STRING ).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Alright, but now it is implemented, do you want it removed? It's like 2 lines and all the scaffolding is there now if there's a need/want for features that take advantage of recipe attributes with arguments. Off the top of my head it could be stuff like [linux("arm64", "amd64")] that enables recipes based on OS + Architecture, or adding kernel version for requirements etc.

But I respect if you invoke YAGNI, then I'll revert it.

Copy link
Owner

Choose a reason for hiding this comment

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

I agree we'll probably add it later, but that could be a while, so I'd assume just remove it. It also makes Attribute::with_arguments simpler, since it can take an Option instead of a Vec.

@CramBL
Copy link
Contributor Author

CramBL commented Jan 12, 2024

I made some semi-related changes to DisplayRange because it was bugged, and I needed to use ranges to make it more generic. I prefer using RangeInclusive because Range just looks ugly when you have e.g. 1..1 which at first glance appears to contain 1 but it is a range of length 0 that does not contain 1.

Now the Display impl for DisplayRange looks pretty messy but it is actually correct now.

Copy link
Owner

@casey casey left a comment

Choose a reason for hiding this comment

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

Added some comments.

@casey casey enabled auto-merge (squash) January 13, 2024 02:42
@casey casey merged commit 8bd411d into casey:master Jan 13, 2024
5 checks passed
@casey
Copy link
Owner

casey commented Jan 13, 2024

Merged! Thank you very much! This release is turning out to have a lot of great contributions ^_^

@CramBL CramBL deleted the add-confirm-prompt branch June 18, 2024 05:49
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