-
Notifications
You must be signed in to change notification settings - Fork 37
feat - add label search argument to sign-invoice #330
feat - add label search argument to sign-invoice #330
Conversation
fdadf76 to
2efe16c
Compare
thomastaylor312
left a comment
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.
2 minor changes here.
Also, it would be great if we could have a --label that does an exact match, but that is optional
yeah that was my original intention as well.I will implement it |
|
@thomastaylor312 can we use the |
|
Those sound like great shorthands |
2efe16c to
c1f102a
Compare
thomastaylor312
left a comment
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.
Awesome! Thanks for going back to make things match. I'll leave this open for a bit in case you want to handle the nit and will merge tomorrow!
| /// In general, if multiple keys match, the implementation chooses the "best fit" | ||
| /// and returns that key. | ||
| fn get_first_matching(&self, role: &SignatureRole) -> Option<&SecretKeyEntry>; | ||
| fn get_first_matching( |
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.
@thomastaylor312 Just thought it would be better to just have one method in the trait rather than having 2 methods that mostly does the same
|
@thomastaylor312 I have just modified the approach here, if you like this approach I will remove the earlier commits !! let me know your thoughts |
thomastaylor312
left a comment
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 actually really like this way of doing it! Just a few comments for discussion
bin/client/main.rs
Outdated
| ClientError::Other(format!("Error loading file {}: {}", keyfile.display(), e)) | ||
| })?; | ||
|
|
||
| let match_type = if sign_opts.label.is_some() { |
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 really like the enum way of doing this!
One nit here: Probably better to do an if let Some(label) = sign_opts.label.as_ref() instead
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.
Used Match now, as we are matching based on 2 expressions, using if let I felt is a bit strange !!
https://github.com/VishnuJin/bindle/blob/e9e0100b3cca0f5301649f6e5d213fd9aab54f56/bin/client/main.rs#L253-L260
src/invoice/signature.rs
Outdated
| fn get_first_matching( | ||
| &self, | ||
| role: &SignatureRole, | ||
| label_match: LabelMatch, |
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 be better if we did Option<LabelMatch> and drop the LabelMatch::None? That might be a bit cleaner and makes it so people don't have to import LabelMatch if they aren't using 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.
yeah, I thought its good to have a Default implementation that can be used in test files etc rather than just using None
but let me know if I can change this to Option<LabelMatch > !!
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 changed it to Option and removed LabelMatch::None
b88180a to
e9e0100
Compare
e9e0100 to
ab0b9b2
Compare
|
@thomastaylor312 this is ready for review now |
| } | ||
| } | ||
| /// This enumerates the select criteria of the key based on the given Label | ||
| pub enum LabelMatch { |
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.
Sorry for another comment here. This is entirely optional, but just wanted your opinion as this API will be used relatively often and I was wondering if this could be cleaner:
pub enum LabelMatch<'a> {
/// Key will be selected with an exact match of the given label.
/// Matches are case sensitive
FullMatch(&'a str),
/// Key will be selected with a partial match of the given label,
/// Matches are case insensitive.
///
/// For example: "pika" will match "Pikachu" and "puff" will match "Jigglypuff"
PartialMatch(&'a str),
}This would make the enum cheap to construct and no need to copy the String. It also would avoid having an Option<&LabelMatch> in a function signature.
We can also just merge and come back to this later, but if you do have an opinion, I'd love to hear 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.
yeah, I had this with lifetime at first but when having it inside first_matching_key function in main.rs I had trouble with the life time reference as expected. Since these string are small I thought its okay to not use reference.
But can I give it another try to have &'a str like before
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.
Nah, no problem. We'll keep this as is and revisit down the line if we want to try again!
fixes #299
this PR adds optional ability to
sign-invoicewith a key that matches the given labelFor example
--label-matching(partial match)--label(exact match)