Add org.freedesktop.Sdk.Tools extension point #105
Conversation
This is similar to org.freedesktop.Sdk.Extension except it is intended for more general tools used by IDEs such as language servers. This would be useful for applications like emacs, atom, vscode, etc.
TingPing
force-pushed
the
tingping/sdk-tools
branch
from
dc61f03
to
274cf56
Compare
| "directory": "bin/sdk", | ||
| "subdirectories": true, | ||
| "no-autodownload": true, | ||
| "autodelete": true |
There was a problem hiding this comment.
I don't think setting autodelete is right. That means any runtime using this extension will remove all the tools when you uninstall it, but multiple runtimes may use these extensions.
|
So, i think this is more or less right. I mean, it means installing a tool does not make it automatically available in PATH/LD_LIBRARY_PATH, so you have to manually do that when using the app. However, this is also what guarantees that installing random tools never break the normal app. Another alternative is to add a similar extension to the app itself, with a well-known name that everyone shares. At this point though, nothing really separates the Tools extension from org.freedesktop.Sdk.Extension, other than the base mountpoint. Is there really a gain in having both? |
|
@gicmo did you try adding an app-specific extension for this? |
This is similar to org.freedesktop.Sdk.Extension except it is intended for more general tools used by IDEs such as language servers.
This would be useful for applications like emacs, atom, vscode, etc, that are development tools using the Sdk as their runtime.
One thought I don't know the best answer to atm: To make
PATHusage easy we want to usemerge-dirsbut I'm unsure how that deals with conflicts. A workaround could be to mergebin/exportsso extensions will only contain clearly chosen binaries which should at least make it manageable but that comes with its own problems. Maybe it just isn't worth it?(I've also not tested this yet, just thought feedback would be useful)