A plugins/theme website

[albertorestifo]

I wanted to work on a plugins and themes website, similar to the Visual Studio Code marketplace.

Before starting on the project, I wanted to ask few questions:

1. Has work on this regard already been done?
2. Is it too early to start (if there is such thing)?

My idea was something quite simple and effective: take advantage of the new repository tags feature of GitHub to fetch and catalog the repositories.

So if you tag the repo as oni-plugin you appear on the plugins page and so on.

[oni-bot]

Hello and welcome to the Oni repository! Thanks for opening your first issue here. To help us out, please make sure to include as much detail as possible - including screenshots and logs, if possible.

[bryphe]

Hi @albertorestifo ,

I wanted to work on a plugins and themes website, similar to the Visual Studio Code marketplace.

That would be incredible! 💯 Having a solid plugin story is the next step on our roadmap, and having a clear, easy way to discover plugins is essential in realizing that.

Has work on this regard already been done?

No work yet! We have our website code here: https://github.com/onivim/onivim.io, but it's mostly static.

The only other mention we have is some work starting on a 'plugins pane' internally in the app (#1431) as a potential entry point for a search experience.

So if you tag the repo as oni-plugin you appear on the plugins page and so on.

This sounds like a great start, and it's nice because we can just use the GitHub API as opposed to needing to provide our own API. This opens the door to discovering Vim plugins.

Later on, I believe we may also leverage NPM, for plugins that utilize Oni's JS/TS API.

One other source that is interesting is vimawesome actually exposes an API, too: https://vimawesome.com/

Is it too early to start (if there is such thing)?

I don't think it's too early to at least get the basics working (like an minimium viable product - just a barebones UX querying against the oni-plugin), since in parallel we'll be starting to materialize a more complete plugin story for the editor. It would be awesome to be able to showcase a marketplace alongside that functionality for our next release (0.4.0), even if its minimal.

Let me know if you'd like to chat more, @albertorestifo . Thank you for proposing this!

[albertorestifo]

Sounds great @bryphe, let's move forward with it then.

I would start by creating a small library which will act as api client shared between the website, the in-editor sidebar and the CLI tool described in #186.

NPM doesn't seem to expose a public API so it would require a server to find packages.

For GitHub, it's pretty straight forward with the GraphQL API. For example:

query { 
  search(first: 10, type: REPOSITORY, query: "topic:oni-theme") {
    repositoryCount
  }
}

As far as using vim-awesome, I don't seem to find a page explicitly documenting the API. It's true that the API the website uses seems well built, but even then, should we use their data? Is it planned to give the possibility of installing a vim theme within the in-editor sidebar? If not then maybe linking to the website is enough.

Once that's done, how much work is left to do before the CLI tool describe in #186 can be implemented?

If it's a lot, then we can start with the website, where the package will contain a quick copy & paste to install it, otherwise maybe completing the CLI before the website is more sensible.

[bryphe]

Sounds great @bryphe, let's move forward with it then.

Excellent! 🎉

I would start by creating a small library which will act as api client shared between the website, the in-editor sidebar and the CLI tool described in #186.

Perfect. GitHub sounds like a great starting point - as long as we are getting some results, we can start testing out the end-to-end flow.

As far as using vim-awesome, I don't seem to find a page explicitly documenting the API. It's true that the API the website uses seems well built, but even then, should we use their data?

I believe there is a Neovim GUI using this, but I could be mistaken. But it definitely doesn't need to be something we incorporate initially - I think the GitHub provider is the perfect starting point.

Once that's done, how much work is left to do before the CLI tool describe in #186 can be implemented?

Regarding the CLI tool - I was actually considering scrapping it, and having these entry points to plugin management:

• API - The Oni API object actually supports installing plugins - this is in the build today. You can run 'Oni.plugins.installer.install("morhetz/gruvbox")` (or any Git/NPM package) from the developer tools, and it will install to the plugins folder. It's still a WIP, but the barebones functionality is there.

• Sidebar - A sidebar experience for adding / installing / uninstalling / enabling / disabling plugins - there's a WIP but not very functional today (you can see what we have so far with sidebar.plugins.enabled set to true). Later, this could be backed by the Oni API object (handling installation/removal/etc of plugins), as well as the new api client for discovering plugins.

• Protocol handler - A protocol handler for something like: oni-install-plugin://git/morhetz/gruvbox. This would let us have an install button on a website 'deep-link' into the install experience, so you can install from the marketplace website.

• Configuration - Not as applicable... but I want to expose a plugins: [..] configuration setting too. But this would be more for a power-user who knows exactly what plugins they want in order to share the config between machines.

Given those pieces of functionality, I'm not sure the CLI is totally necessary - at least not for this PoC.

What we could try is maybe creating a simple menu that calls the API:

    
    const menu = oni.menu.create()
    menu.show()
    menu.setLoading(true)
   
    fetchPluginsFromNewApiClient().then((results) => {
            const menuItems = convertPluginResultsToMenuItems(results)
            menu.setItems(menuItems)
            menu.setLoading(false)
    }) 
    menu.onItemSelected.subscribe((selectedValue) => oni.plugins.installPlugin(getInstallPathFromMenuItem(selectedValue))

This would give us a really bare-bones experience we could try out - we spin up a menu that calls the API client, show the menu, and then allow for installing it based on the value. The main gaps we'd need to fill in to test this out are implementing fetchPluginsFromNewApiClient (using your API client), implementing convertPluginResultsToMenuItems (convert the results to what the menu needs - a label and a detail), and then getInstallPathFromMenuItem, which would give us the github path fro the menu item.

We could put a button in the WIP sidebar pane to expose this - like 'Discover Plugins' - and test it out end-to-end 👍 And then of course increment and improve - it'd be nice to show details about the plugin later, have a confirmation prompt for installing, etc.

@albertorestifo , does that seem like an OK way to test the API client?

From the website, we could start stubbing out an oni-install-plugin protocol handler, too, to build out that entry point. It would be fun to have an 'Install' button that at least opens up Oni - and then we could work from there to build out hooking it up to the install-plugin API.

Either of those actually seem cheaper than the CLI to me at this point - and would be a relatively short path to getting something working end-to-end that we could iterate and improve on.

Let me know what you think! Thanks again for your help with this, @albertorestifo 👍

[CrossR]

I believe there is a Neovim GUI using this, but I could be mistaken. But it definitely doesn't need to be something we incorporate initially - I think the GitHub provider is the perfect starting point.

https://github.com/daa84/neovim-gtk uses it in their Plugin Manager as far as I know.

[albertorestifo]

Everything you said @bryphe makes total sense to me and I agree the CLI tool is not really needed.

If it sounds good to you, I'll proceed in the following order:

• Step 1: Discovery tool - Create a repo and package named oni-extensions-dicovery, which for now will only deal with plugins, but it can grow with time to handle installing any vim plugin, theme or oni themes and whatnot

• Step 2: In-editor sidebar - Integrate the plugins discovery in the editor sidebar in the simples way and call the already-built install function. In this iteration, clicking a plugin will open the README.md in the in-editor browser.

• Step 3: Improvments - Iterate on the sidebar and discovery experience. That's where we integrate themes, vim plugins, improve the design of the sidebar or whatever else we see it's more important once we start testing the system

• Step 4: URL Install protocol - Implement the oni-extension install protocol. It should be too much work

• Step 5: Website - I think it makes sense to work on the website only once all the other pieces are in place. It's better to have a nice in-editor experience before having a website. What do you think?

• Step 6: Replace README.md - Clicking on a plugin in the sidebar won't open the GitHub README.md anymore but instead a dedicated/slightly modified view of the plugin page on the website, same as VS Code basically

Sounds good?

[bryphe]

@albertorestifo - excellent roadmap! The plan sounds great and the breakdown makes sense to me. 💯 I like that we get a simple end-to-end working relatively early in step 2 - that will be a good foundation for us to improve and iterate on.

Agree with having the website be at the end - I envision the in-editor experience will be the primary entry point.

Keep me posted and let me know if you need anything! Our discord is a great place to chat too: https://discord.gg/7maEAxV

For step 1 - would you like me to start by creating an oni-extensions-discovery repo here?

[albertorestifo]

@bryphe that would be awesome! I'll join the discourse and start working on it whenever I get a chance!

Happy to be able to help the project.

[bryphe]

@albertorestifo - perfect! I just created the repo here: https://github.com/onivim/oni-extensions-discovery and I gave you write permissions for it, so you should be able to push freely to it.

Let me know if there is anything else I can do to help 👍

[albertorestifo]

@bryphe Awesome, I'll keep you posted.

[DeltaEvo]

@albertorestifo npm have a public api, but it's undocumented (shame on you npm), the api is exposed by the registry and used by the npm cli they use a client for this

The search api can be used very simply http://registry.npmjs.org/-/v1/search?text=oni-vim

The npm api even set a CORS Allow Header Access-Control-Allow-Origin: * \o/, seems that this feature don't need a backend 💯

[albertorestifo]

That's awesome!

On another note, I can't use the GitHub GraphQL API because the search doesn't allow unauthenticated calls.

[DeltaEvo]

Yeah the GraphQL v4 API need authentication for all actions, to do unauthenticated call the V3 API seems more adapted
(The search endpoint on the V3 API don't seems to require authentication)