Derive macro for plugin option parsing

[adevore]

Related problem

Plugin command signatures and option handling has significant boilerplate. Information like error handling and conversion is fairly manual. The signature and certain behavior are in separate pieces of the program.

Describe the solution you'd like

A derive macro to allow plugin commands to declare their arguments. Ideally it should follow a similar API to clap's derive macro. That means following both an API that is proven and is familiar among Rustaceans. It can be built mostly on top of the nu_protocol::FromValue trait.

Describe alternatives you've considered

No response

Additional context and details

I am interested in working on this feature. I have limited experience in nu and derive macros, but after digging into syn, quote, and proc macros it feels doable.

In parallel, I am working on an LDAP plugin. That can be a test ground for how it looks on a real world plugin.

[fdncred]

Is this what you're talking about mimicking? https://docs.rs/clap/latest/clap/_derive/_tutorial/chapter_0/index.html

We used to use clap for our nushell command line parsing but removed it because it was either too slow to compile or too big. I can't remember which.

I think we could make it easier somehow like naming the parameter functions more intuitively. I'm not sure if what you're suggesting is a good way to go. I'm interested in what it would look like which is why I went looking for an example.

[adevore]

Yes, that's what I was thinking of mimicking. I found a ticket from 2018 discussing clap's size. It sounds like the help strings are somewhat large. This shouldn't be an issue here since a manual implementation already includes strings that would correspond to the generated output.

I'm not too familiar with proc macro compile time characteristics. From what I can tell, it doesn't make too much of an impact to add in a proc macro that runs once per plugin.

[adevore]

How about this. I don't think this needs any changes to the core of Nushell, even if it would benefit from living in the workspace. Therefore, I can work on a proof of concept implementation out of tree that can be merged in later. If compilation times are a problem, it could be behind a feature flag on the nu-plugin crate if it does get merged.

[fdncred]

You're welcome to work on it if you want but I can't promise that we'll accept the eventual PR. If it makes things overwhelmingly easier to use and understand, then there's probably a good chance it would be accepted. The problem with my statement is that it's subjective.