Addon Manager #1607
Replies: 6 comments 36 replies
-
It is great idea😁. How about keeping definitions for libraries in separate repositories and somehow add a link to them in the repository here? And in the settings when downloading the extension, it will be possible to check the boxes for those libraries that will be needed, and then only they will be downloaded. This seems to get rid of two problems:
We are slowly making a library too and it would be great to embed it natively in the language server. But we will constantly update it, so it's more convenient if we work in our own repository. |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
-
Yet another progress report. I have refined things a lot further, and I think it is ready to integrate. @sumneko, how should we go about discussing merging it in? It is a pretty big addition and makes a few modifications to the VS Code client such as adding a new setting and refactoring some of the code. I'm not 100% sure how your build and release workflows work, so I could use some help integrating my code so that it can install its dependencies and build correctly without interrupting your workflow. I did some more testing, and it turns out the GitHub API has a rate limit of 60 requests per hour for unauthenticated traffic. So I spent a bit more time on the sign-in process and making it more clear why it is pretty much mandatory. |
Beta Was this translation helpful? Give feedback.
-
The addon manager is great for VS Code users, but what is the plan for other clients? VS Code users will no longer need the addons to be included in Personally, I think libraries should be installed by the user and not just included in the language server. I think the server should just be the server, and libraries/addons should be installed with intent by the user. This prevents bloat and the user having libraries that they never plan to use. I have only ever used the included Alternatively, there could be a setting that is a list of git remotes that the language server could make sure are installed. This way the addon manager can add addons to the list, other clients can easily add links in there and let the server handle it, and when you share your project with someone, assuming they have the server, it would install the needed libraries. @sumneko interested to hear your thoughts. Ideally we can find a solution that works for all clients 🙂 |
Beta Was this translation helpful? Give feedback.
-
Looking at the progress made, would it also be possible to add support for luarocks, the lua package manager? So the ui would let you add luarocks dependencies, and lls would adjust the path as such @carsakiller |
Beta Was this translation helpful? Give feedback.
-
There has already been some discussion on this topic, but I wanted to create a discussion dedicated to the topic before things get even harder to track there.
Intro
With over 500k installs in VS Code (:tada:), there is a lot of documented Lua out there. People are also creating lots of definition files for providing documentation and completion. To help people find and use these definition files, there should be a more complete solution.
Current Solution
The current method for discovering definition files is just searching around on the internet or by taking a browse through the meta files thread. A thread is definitely not the best medium for finding definition files, though.
Once you find the definition files, you have to download them and manually enable them by specifying their path through
workspace.library
orworkspace.userThirdParty
. This isn't terribly hard, but a user can't enable a library if they can't find it, so discovery should be a priority.Possible Solution
There is a lot that could be done to improve the experience. This is my opinion with some thought put towards it, but I am of course open to feedback, so feel free to join in on the conversation!
Official Definition Repository
There should be a new repository created that stores the definition files of the definitions currently included in the language server. Those files currently included in the source code can then be removed and moved to this new repository. This also has the bonus of letting people contribute to these definition files without opening issues and PRs on the language server repo. This repo can then grow to document all kinds of projects, similar to how DefinitelyTyped works for TypeScript.
Community Definitions
Should someone have definition files that they haven't or maybe don't want to add to the official repository, they should still be able to use them. Users can then manually include these “custom” definitions similarly to how it presently works.
Discovery and Installation of Official Definitions
Using the GitHub API and GitLab API it is possible to programmatically get all the projects in the new official repository.
Now, the language server could download the
config.lua
(if existing) for each project, but at some point, there will be a lot of projects defined in that repo. I'm not sure how performant it would be to download hundreds of config files and run them all. I instead propose users opt-in to the definitions they want installed. This can be done in VS Code through the extension's webview API, and could look something like this:As for NeoVim, I have never used it, so I don't know if they have any similar function. We could always create a github.io site that allows users to browse through the available projects in an equally easy-to-read and “pretty” way. They could then download them directly from that site and be prompted with instructions of where the downloaded files should go and what settings they need to modify to enable the definitions.
Beta Was this translation helpful? Give feedback.
All reactions