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

Provide documentation and templates to write extensions #1367

Open
ghost opened this issue Jul 31, 2023 · 4 comments
Open

Provide documentation and templates to write extensions #1367

ghost opened this issue Jul 31, 2023 · 4 comments
Assignees

Comments

@ghost
Copy link

ghost commented Jul 31, 2023

Could you write a standard document or example on developing sliver extensions (C++/Go)? If so, everyone could follow this standard to develop and contribute plugins. Wouldn't that be a very cool thing?

@rkervella
Copy link
Member

We plan on making a repo with bootstrap template for extensions in different languages, but that's not done yet. So far there's no official documentation afaik, only community created ones like this one.

@rkervella rkervella self-assigned this Jul 31, 2023
@rkervella rkervella changed the title May I make a small suggestion Provide documentation and templates to write extensions Jul 31, 2023
@ghost
Copy link
Author

ghost commented Aug 2, 2023

When is the bootstrap template expected to be available, thank you at the same time

@rkervella
Copy link
Member

No ETA.

@maxlandon
Copy link
Contributor

maxlandon commented Aug 29, 2023

@moloch-- @rkervella

Here is one stone to kill n birds:

https://github.com/rsteube/carapace-spec

Use this as the schema for the command syntax of extensions (don't get me wrong: just for the command field of the extension spec).

As well, include the now widely used directive$shema path/to/yaml/json/schema into the extensions template root file.

Advantages:

  • The spec above is meant to be consistently parsed into cobra command trees, for any shell. Since everything in Sliver is now a cobra command, using this spec ensures that everything will be parsed correctly.
  • You can declare commands, flags and positionals with all possible specs and variants.
  • you end up having not only a command syntax spec for your extensions, but you also get free completion for them, at arbitrary levels of complexity.
  • Totally opt-in: people don't even have to know that this is a completer spec, since it's first and foremost a command tree declaration spec.
  • Including the s$shema directive in the extension file provides validation, documentation and completion within editors with support for it.

Disadvantages for now:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants