-
-
Notifications
You must be signed in to change notification settings - Fork 6
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
refactor: further separate CLI logic from the API related functionality (see #117) #124
base: v3
Are you sure you want to change the base?
Conversation
…for each subcommand
…se `style_edition` instead.
CodSpeed Performance ReportMerging #124 will not alter performanceComparing Summary
|
Hi @Rolv-Apneseth! I have quickly looked at your PR, it looks very good! I will give it a better look later, but let me answer your first questions.
Well, I think So in conclusion,
We can give it a try :-) |
…ute` for each variant of `Command`
Great!
Sorry, I meant which things in let text = std::fs::read_to_string(filename)?;
let requests = request
.clone()
.with_text(text.clone())
.split(self.max_length, self.split_pattern.as_str());
let response = server_client.check_multiple_and_join(requests).await?; And for the
I've added it in there - I think it fits nicely. |
I've pushed some changes there for this, avoiding the need to clone the input text. |
Yes,
I think using
Yes and no. Yes because
Yes, this would be great. The split-text logic isn't really trivial to solve, because we want to avoid splitting text where it would break the meaning of a sentence, but also we cannot have long-running text either. I think working on a better split-logic can be a next step. For the moment, we can just use
Yes, the end-goal would be to remove the complex logic from |
Hey again. Had a lot of trouble with lifetimes and I could only get |
Hello @Rolv-Apneseth, rapidly looking at your commit, I think you just forgot to add the lifetime parameter in However, it makes little sense to have reference in responses, because This will replicate a similar behavior to that of |
.as_ref() | ||
.ok_or(Error::InvalidRequest("missing text field".to_string()))?; | ||
pub fn try_split(mut self, n: usize, pat: &str) -> Result<Vec<Self>> { | ||
let text = mem::take(&mut self.text) |
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, one goal would be that try_split
returns a reference to &self
, so the signature should be as follows:
pub fn try_split<'source>(&'source self, n: usize, pat: &str) -> Result<Vec<Self<'source>>>
Note that we should not need to mutate the actual request, because we only take references.
I can have a go again but something was complaining about needing to live longer than |
No issue. If you can't make it compile, just push with |
So this code: #[cfg_attr(feature = "cli", derive(Args))]
#[derive(Clone, Debug, PartialEq, Eq, Serialize, Hash)]
#[serde(rename_all = "camelCase")]
#[non_exhaustive]
pub struct Request<'source> {
/// The text to be checked. This or 'data' is required.
#[cfg_attr(
feature = "cli",
clap(short = 't', long, conflicts_with = "data", allow_hyphen_values(true))
)]
#[serde(skip_serializing_if = "Option::is_none")]
pub text: Option<Cow<'source, str>>, Leads to this error:
So I don't think it will work as it is. Should I take out |
Oh yeah, I remember why I struggled with Creating a separate struct would work, but that means duplicating a lot of the code. I wonder if there is still a way to allow |
Not that I can think of anyway. I'd say the options are to either stick with |
Ok so some news: at the moment, it seems impossible to do that in one struct, see clap-rs/clap#5773 and the related discussion, so I suggest we duplicated the structure: to original |
I think it would have to be a procedural macro right? Can't see how to do that with a declarative one. I have a bit of time today so I'll have a look but feel free to do it if you have a good idea of how it should be done |
I actually started some work on your branch today, I will hopefully have something working this afternoon :) |
Oh nice, good luck |
Ok so it compiles with I am looking a possible crates that might provide useful tools to avoid rewriting most of the code. |
Unfortunately, I haven't been able to put more work on this PR this weekend, sorry for that. I fear more and more that the copy/paste option would be the only way of solving this. |
Hey - been busy moving this weekend. If I have any time in the coming days I can have a look for any crates that could solve this problem - if not, yes, copy paste might have to do for now |
No issue! Yeah, maybe let's copy and paste (keeping the |
Yeah couldn't find any crates for this situation. I do think just copying the struct is better but to provide another option, what do you think of something like this: pub struct Request<'source> {
// HACK: keep compiler happy when enabling the cli feature flag
#[cfg(feature = "cli")]
#[clap(skip)]
_lifetime: PhantomData<&'source ()>,
/// (...docs)
#[cfg(feature = "cli")]
#[clap(short = 't', long, conflicts_with = "data", allow_hyphen_values(true))]
#[serde(skip_serializing_if = "Option::is_none")]
pub text: Option<Cow<'static, str>>,
/// (...docs)
#[cfg(not(feature = "cli"))]
#[serde(skip_serializing_if = "Option::is_none")]
pub text: Option<Cow<'source, str>>,
/// (...docs)
#[cfg(feature = "cli")]
#[clap(short = 'd', long, conflicts_with = "text")]
#[serde(skip_serializing_if = "Option::is_none")]
pub data: Option<Data<'static>>,
/// (...docs)
#[cfg(not(feature = "cli"))]
#[serde(skip_serializing_if = "Option::is_none")]
pub data: Option<Data<'source>>, As for the upstream issue - I had a look but I believe it's beyond my skills. Needs quite a bit of familiarity with how their derive macros work, and the author seems to agree having assigned it that |
This is not a wrong idea, but the issue is that compiling with This is an edge case, but we don't want to have to keep a static lifetime reference to the content of each file, where we don't need it. So copying the struct is the only we to both have Clap happy and still be able to use non-static lifetime when desired.
I agree, this is not easy, especially as it involves proc macros! |
Continuation of #117.
As discussed, some refactors. You will probably want some more done here and that's OK, just let me know what to do.
One thing for sure is the
String
values inapi/check.rs
- which ones exactly would you like me to make&str
orCow<'_, str>
?Also, for
cli/mod.rs
, I could potentially remove the need for the manual call ofcmd.execute
for each subcommand using the enum_dispatch crate if you're OK with adding a dependency? Fine as it is anyway though in my opinion, as there aren't many subcommands.