-
Notifications
You must be signed in to change notification settings - Fork 48
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
Add RFC: Unified Plugin Packaging Format #35
Conversation
I've rewritten some parts of the RFC in order to be much clearer on how the implementation should work. Additionally future additional "platforms", like "lua" (for Lua cross-platform plugins) can now also be supported with ease. I'd love to get some feedback on this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I notice #34 covers min/max versions of OBS that individual plugins are compatible with, and that this RFC only mentions system-level versioning. If I'm reading this correctly, that means that a plugin can only be shipped with a single minimum version of OBS in mind, but multiple versions for multiple operating systems - say, one that's compatible with Windows 10.0.19041 (20H1) and 10.0.19042 (20H2) separately.
Personally, I think a plugin should be comfortable shipping a slightly older version of itself within the same ZIP for manual installation. We already know a lot of users won't immediately update to a major OBS version, and will instead stick to the previous version to ensure all bugs are found. Being able to download one ZIP that contains builds compatible with the last 2 minor OBS versions seems beneficial.
Obviously a built-in Updater in OBS would not care about such a structure, because it could just download a compatible ZIP rather than the latest, but I want to make sure our bases are covered.
text/0000-plugin-package-format.md
Outdated
|
||
- `/<name>/data` | ||
The plugins custom data, such as localized text and images. | ||
- `/<name>/bin/<platform>/[.../]<name>[.<ext>]` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm reading this correctly, only the file with the same name as the plugin's directory will be loaded directly, correct? In that case, say we're talking about obs-browser which includes a libcef.dll
, that'd also be placed in /<name>/bin/<platform>/[.../]
alongside obs-browser.<ext>
, yes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, so for your example obs-browser, it will only attempt to load obs-browser.so and ignore all other files. Those files are left up to the plugin itself to load, if at all.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
The updated RFC should now be able to do this, though it has the same "minimum only" restriction.
Also now taken care of. Managers/Updaters most likely have no reason to download binaries which do not match the Host OS, so that was a good point. |
If #41 is accepted, this RFC requires an update to the |
Closing as requested. |
Description
Proposes a unified structure for plugins to follow across all platforms, instead of the weird mixture OBS currently has across all supported platforms. Additionally some optional design choices are included, if these are necessary.
Motivation and Context
Currently all platforms have their own way of shipping platforms, some even being different by the way they are installed (system-wide vs local-user), which results in higher difficulty when shipping cross-platform plugins. The current behavior also prevents some much needed future features from even working correctly.
Link to RFC