Bringing the addon manager to everyone

[carsakiller]

This discussion has been replaced by #2408

---

The addon manager seems to be working pretty smoothly now and is serving its initial purpose of making discovery and installation of definition files easier 🥳. However, there has always been a rather large compromise with the addon manager; it only works for VS Code users. This leaves a lot of people in the dark.

There are two problems with bringing the addon manager to everyone:

1. Each editor would need its own UI extension (if even possible)
   • Each editor is going to have their own APIs and methods for implementing a UI. Some editors may not even have a way to add a customized UI. Ideally, we could re-use WebVue, but it requires support for displaying a webpage and communicating through MessagePorts, and still will likely just not work.
2. All the logic for installing, enabling, etc. would have to move elsewhere.
   • The logic for managing addons currently exists in the VS Code extension for the language server. Making it available for others will definitely require the logic to move elsewhere.

Possible solutions

The addon managing logic could maybe be moved into the language server, this way, wherever the language server goes, the addon manager goes. However, I don't even know where to begin with interacting with Git and the filesystem from the language server in Lua.

It also is possible to instead use the language server to host the UI locally, the editor can then just open the website in an iframe (which as far as I know, still wouldn't work in NeoVim) or browser. This would again require the addon managing logic to move to the language server.

The addon manager could also just be a simple CLI tool and the fancy UI could be thrown out, but this seems like a significant downgrade for VS Code users.

And finally, I could possibly make a separate executable that fires up the website locally, allowing it to be visited in an iframe or browser.

---

I am interested in what you guys think. I am not sure how many people are truly missing out on the addon manager, or how important a UI is. So please, let me know what you think 🙂

[goldenstein64]

I think that a CLI tool would be awesome, and making the UI depend on the CLI tool would be the best way to bring the addon manager to everyone, that way all UI implementations would use the same communication layer to find and use all the addons, and the CLI can still be used directly for those that don't have a UI.

The CLI could take an approach similar to the existing interface, like this.

# show a help message
# might also show other information like server path, logs, feedback
lls-addon help
lls-addon --help
lls-addon -h

# get the CLI's version
lls-addon --version
lls-addon -v

# get the language server path
lls-addon server

# set the language server path
lls-addon server <path>

# enable an addon, install if necessary
# like clicking the 'Enable' button
lls-addon enable <addons...>

# disable an addon
# like clicking the 'Disable' button
lls-addon disable <addons...>

# uninstall an addon, disable if possible
# like clicking the 'Uninstall' button
lls-addon uninstall <addons...>

# show a list of addons
lls-addon list [page]
    --filter <category> # show a certain category of addons, can be specified multiple times

# show information about an addon
lls-addon show <addon>
    --field path # show a certain field of the addon, can be specified multiple times
    --field github
    --field name
    --field description
    # etc.

To help facilitate UI communication, you could add a --json option to output a JSON object instead of plain text, especially for the commands that output information like lls-addon show or lls-addon list.

Personally, I don't need a UI for the addon manager, but I also think it's more user-friendly than the CLI.

[carsakiller]

I am conflicted. Part of me feels like creating a separate CLI in Go or something would be relatively easy and would, like you have demonstrated here, make it easy for me to add commands that won't conflict with the language server.

However, it does mean I have to redo some of the functionality that is already in the language server, like editing the configuration files. It also means it has to be installed separately alongside the language server.

I think I will continue with trying to jam it into the language server for now. I do like your ideas here though.

[carsakiller]

@sumneko How can I get set up for developing the language server? I am trying to create a Docker container that contains all the tools and things needed for the language server. Ideally, this allows people to very quickly get the complete environment up and running, independent of hardware. Using the VS Code dev container extension, you should also be able to connect to and develop the language server, entirely within the container. Assuming I can get it to work, I can then share the dockerfile as well to help others get up and running easily.

I have a few questions though:

The language server should be able to be run in the container and then port forward out to the VS Code client. Is this possible? Does the VS Code client allow me to specify a separate IP/Port rather than the server started by the extension?

What are the steps for getting set up to develop from scratch (from nothing to language server running)? I think I have figured this out

[carsakiller]

I'm going to be honest, I have pretty much no idea what I am doing here 😆. I've got some basic Lua for checking for Git and cloning LLS-Addons, but I am not sure how to call my code from the command line (like lua-language-server addon-enable luassert??) and integrate it with everything that already exists.

[sumneko]

I will save it into _G['ADDON-ENABLE'] = 'luassert' now, you can handle it in script\cli

[carsakiller]

Okay, I am able to execute my code from the command line. I am also able to interact with Git.

How can I edit the user's config? I need to be able to, for example, add a new path to workspace.library. I found config.add() but it requires a uri?

[goldenstein64]

As far as I can tell, the uri can point to the workspace folder or any file/directory in a workspace folder. They all resolve to the config file linked to that folder, see config.set > getScope > scope.getFolder(uri) > scopeMt:isChildUri from config.config and workspace.scope

I think you can get uris by looping through scope.folders from workspace.scope?

local scope = require 'workspace.scope'

for _, folder in ipairs(scope.folders) do
    local uri = folder.uri
    -- do stuff
end

I don't really know how to get a uri specific to their current workspace. Maybe you can get their current file and pass that into config.add?

[carsakiller]

That is the problem, I need a way to apply a configuration to a specific workspace. I need to read workspace.library, check if the addon is already added, and if it isn't, add it.

[carsakiller]

I am currently planning on changing the way the addons are retrieved. Having them all in the LLS-Addons repo is nice for discoverability, but I think it will have trouble scaling due to the whole repo being cloned.

The safest solution is to simply provide the git clone URL for the desired addon:

./lua-language-server addon-enable https://github.com/LuaCATS/luafilesystem.git

The language server would then use Git to install the luafilesystem addon and enable it. This allows for a lot of flexibility when it comes to what addons can be enabled and from where. However, this then ruins discoverability as you would no longer be able to list and install the “official” addons simply using their name. Something that I never originally considered with the current implementation, but happened to work out, is a lot of addons have a specific release branch—this method wouldn't allow for that.

---

I think it would make sense to not clone LLS-Addons, as is done currently, and instead have the LLS-Addons repository publish a GitHub Pages website that is just simply the needed JSON data. The language server can then just retrieve that instead of having to clone the whole repo with the git history and whatnot.