-
Notifications
You must be signed in to change notification settings - Fork 85
Introduce "plugin stages" #68
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
Comments
That would be great. Currently I'm using a 2 calls process as:
But actually I could even use a 3rd call, where the plugin is run again just before generating the AppImage. |
In your case, a single call might be sufficient already, though. But yes, this would be useful. |
In my case |
Your plugin should not depend on subsequent runs of linuxdeploy I guess, or maybe call it automatically then. But it's probably preferrable to use C++ with liblinuxdeploy for it then. I don't know how plugin stages could work around that. Especially since I already mentioned in your tracker that it's preferable for your plugin to use a different prefix. Anyway, plugin stages are definitely planned. |
Instead of limiting us to "input" and "output", I would like to add a few stages in between. This way, plugins get more flexibility when they're called (some might want to add libraries before linuxdeploy "does its thing" for instance to not have to build upon the linuxdeploy framework for instance, some might want to be called after the deployment of the files to the AppDir root has been finished but right before the output plugins are called, ...).
We might extend that idea with some sort of "priority" to be able to run plugins with dependencies in the right order.
The text was updated successfully, but these errors were encountered: