Plugin Mechanism #9126

@lunny commented on GitHub (Jun 25, 2022):

I prefer the plugin system based on javascript or nodejs because that will allow it include frontend code.

Possbile library be used. https://github.com/dop251/goja, there is also a plugin support nodejs .

@lunny commented on GitHub (Jun 25, 2022): I prefer the plugin system based on javascript or nodejs because that will allow it include frontend code. Possbile library be used. https://github.com/dop251/goja, there is also a plugin support nodejs .

GiteaMirror commented

@delvh commented on GitHub (Jun 25, 2022):

Interesting how many different views there are regarding this feature.
Now we have three completely different options and no agreement on what to use...

@delvh commented on GitHub (Jun 25, 2022): Interesting how many different views there are regarding this feature. Now we have three completely different options and no agreement on what to use...

GiteaMirror commented

@lunny commented on GitHub (Jun 25, 2022):

Interesting how many different views there are regarding this feature. Now we have three completely different options and no agreement on what to use...

Use javascript based plugin system, we can implement a plugin market and one click installation. That's impossible for Go based plugin system.

@lunny commented on GitHub (Jun 25, 2022): > Interesting how many different views there are regarding this feature. Now we have three completely different options and no agreement on what to use... Use javascript based plugin system, we can implement a plugin market and one click installation. That's impossible for Go based plugin system.

GiteaMirror commented

@delvh commented on GitHub (Jun 25, 2022):

The problem I can see is: We do not even have the same definition of what we want in the end:
What you want seems to be a per-user plugin mechanism, what I thought of was a per-instance plugin mechanism...

@delvh commented on GitHub (Jun 25, 2022): The problem I can see is: We do not even have the same definition of what we want in the end: What you want seems to be a per-user plugin mechanism, what I thought of was a per-instance plugin mechanism...

GiteaMirror commented

@lunny commented on GitHub (Jun 25, 2022):

The problem I can see is: We do not even have the same definition of what we want in the end: What you want seems to be a per-user plugin mechanism, what I thought of was a per-instance plugin mechanism...

I don't think so. I think I'm also talking about per-instance plugin. If I made you confusing, I'm sorry.

@lunny commented on GitHub (Jun 25, 2022): > The problem I can see is: We do not even have the same definition of what we want in the end: What you want seems to be a per-user plugin mechanism, what I thought of was a per-instance plugin mechanism... I don't think so. I think I'm also talking about per-instance plugin. If I made you confusing, I'm sorry.

GiteaMirror commented

@jolheiser commented on GitHub (Jun 25, 2022):

-1 for the go plugin package.
It can't be removed per compatibility promise, but it is absolutely not stable, and there are far too many caveats to get it working properly.

@jolheiser commented on GitHub (Jun 25, 2022): -1 for the go `plugin` package. It can't be removed per compatibility promise, but it is absolutely not stable, and there are far too many caveats to get it working properly.

GiteaMirror commented

@lunny commented on GitHub (Jun 25, 2022):

I think we can begin from a theme-kind plugin, which is simple and useful. A plugin could be a zip/tar file with a main.js or index.js and other files like theme.sass, theme.css and images and etc.

@lunny commented on GitHub (Jun 25, 2022): I think we can begin from a theme-kind plugin, which is simple and useful. A plugin could be a zip/tar file with a `main.js` or `index.js` and other files like `theme.sass`, `theme.css` and `images` and etc.

GiteaMirror commented

@wxiaoguang commented on GitHub (Jun 25, 2022):

I do not think the Go's plugin package is the future. Is there any success story of using it?

Most large Go projects uses gPRC for inter-process commutation, including plugins, but it's also heavy.

@wxiaoguang commented on GitHub (Jun 25, 2022): I do not think the Go's `plugin` package is the future. Is there any success story of using it? Most large Go projects uses gPRC for inter-process commutation, including plugins, but it's also heavy.

GiteaMirror commented

@delvh commented on GitHub (Jun 25, 2022):

Ok, seems as if the plugin package is generally disliked, so I'll exclude it from the possible options.

I'm still not a fan of a purely frontend-based plugin mechanism as that will have many shortcomings of its own, and I don't know if

plugin market and one click installation.

should be the deciding factor for how to implement the plugin system...
Server admins should be sure of what they want for their instance, and not install it with a simple misplaced click.
Also, even with the Go-based approach, a plugin "market" would be possible as a third-party tool that simply stores the executables and perhaps some other information about the plugin...

So, as I can see that now, the two possible options are

a backend-based plugin mechanism (most likely using go-plugin)
a frontend-based plugin mechanism (no idea how to implement that - I didn't see anything practical in the link you sent, @lunny ?)
Did I miss something else?

@delvh commented on GitHub (Jun 25, 2022): Ok, seems as if the `plugin` package is generally disliked, so I'll exclude it from the possible options. I'm still not a fan of a purely frontend-based plugin mechanism as that will have **many** shortcomings of its own, and I don't know if > plugin market and one click installation. should be the deciding factor for how to implement the plugin system... Server admins should be sure of what they want for their instance, and not install it with a simple misplaced click. Also, even with the Go-based approach, a plugin "market" would be possible as a third-party tool that simply stores the executables and perhaps some other information about the plugin... So, as I can see that now, the two possible options are - a backend-based plugin mechanism (most likely using `go-plugin`) - a frontend-based plugin mechanism (no idea how to implement that - I didn't see anything practical in the link you sent, @lunny ?) - Did I miss something else?

GiteaMirror commented

@luwol03 commented on GitHub (Jun 25, 2022):

Isn't this library lunny suggested meant for a backend-based plugin mechanism? But instead of writing go you can write js? Or would that be to difficult to build a bridge between the Gitea go code and js code?

@luwol03 commented on GitHub (Jun 25, 2022): Isn't this library lunny suggested meant for a backend-based plugin mechanism? But instead of writing go you can write js? Or would that be to difficult to build a bridge between the Gitea go code and js code?

GiteaMirror commented

@lunny commented on GitHub (Jun 25, 2022):

Yes, it could expose structs, methods to frontend. i.e. If we expose getdb method, then we can operate database with javascript.

@lunny commented on GitHub (Jun 25, 2022): Yes, it could expose structs, methods to frontend. i.e. If we expose getdb method, then we can operate database with javascript.

GiteaMirror commented

@lafriks commented on GitHub (Jun 25, 2022):

I think the best way to go would be using grpc so that plugins could be implemented using any language. Plugin could return asset files on init (JavaScript etc) that would need to be injected/used in specific places

@lafriks commented on GitHub (Jun 25, 2022): I think the best way to go would be using grpc so that plugins could be implemented using any language. Plugin could return asset files on init (JavaScript etc) that would need to be injected/used in specific places

GiteaMirror commented

@jolheiser commented on GitHub (Jun 27, 2022):

I would also like to throw yaegi into the mix.
I think gRPC is probably the only way to go (unfortunately), but figured yaegi is worth considering as well.

@jolheiser commented on GitHub (Jun 27, 2022): I would also like to throw [yaegi](https://github.com/traefik/yaegi) into the mix. I think gRPC is probably the only way to go (unfortunately), but figured yaegi is worth considering as well.

GiteaMirror commented

@Mai-Lapyst commented on GitHub (Jun 27, 2022):

Honestly, I would like to see the native go plugin implementation.
Yes it has drawbacks, but it would be fast and admins had full controll over what to use.

But since thats off the table for now, I would rather go with the gRPC approach, since its more open (i.e. you can choose more languages) and imo more secure then javascript.

The problems I see with js plugins is, that it lead to a huge security risk, since js can be so minified or encrypted that you not even need any letters (only parentheses) to write correct js. We then would need an very strict system so no js can accidentally just execute "DROP ALL TABLES;" (or similar) on startup.

Also an interpreter (of any kind) in gitea would bring back the risk of one plugin crashing the whole instance, or to eat up so much performance that gitea stops responding (i.e. a infinite loop in a script somewhere). To mitigate this we then would need to sandbox the plugins into own processes, which would nearly the same as the gRPC approach but with less freedom.

@Mai-Lapyst commented on GitHub (Jun 27, 2022): Honestly, I would like to see the native go plugin implementation. Yes it has drawbacks, but it would be fast and admins had full controll over what to use. But since thats off the table for now, I would rather go with the gRPC approach, since its more open (i.e. you can choose more languages) and imo more secure then javascript. The problems I see with js plugins is, that it lead to a huge security risk, since js can be so minified or encrypted that you not even need any letters (only parentheses) to write correct js. We then would need an very strict system so no js can accidentally just execute "DROP ALL TABLES;" (or similar) on startup. Also an interpreter (of any kind) in gitea would bring back the risk of one plugin crashing the whole instance, or to eat up so much performance that gitea stops responding (i.e. a infinite loop in a script somewhere). To mitigate this we then would need to sandbox the plugins into own processes, which would nearly the same as the gRPC approach but with less freedom.

GiteaMirror commented

@delvh commented on GitHub (Jun 27, 2022):

To be fair, you can also DROP ALL TABLES; in Go or consume all available memory.
But yeah, I can see your point.

@delvh commented on GitHub (Jun 27, 2022): To be fair, you can also `DROP ALL TABLES;` in Go or consume all available memory. But yeah, I can see your point.

GiteaMirror commented

@luwol03 commented on GitHub (Jun 27, 2022):

Then you have to think twice about an official plug-in market like lunny suggested. Official also indicates that they are save for usage and have no malicious intentions. An easy one click install could potentially break servers from not experienced users who don't understand what the plugin is doing and just pressing install.

To prevent this, this would at least requires some reviewing and analysis of newly published plugins, which is time expensive.

@luwol03 commented on GitHub (Jun 27, 2022): Then you have to think twice about an official plug-in market like lunny suggested. Official also indicates that they are save for usage and have no malicious intentions. An easy one click install could potentially break servers from not experienced users who don't understand what the plugin is doing and just pressing install. To prevent this, this would at least requires some reviewing and analysis of newly published plugins, which is time expensive.

GiteaMirror commented

@lafriks commented on GitHub (Jun 27, 2022):

We could probably get some ideas on how mattermost have implemented their plugin system.

@lafriks commented on GitHub (Jun 27, 2022): We could probably get some ideas on how mattermost have implemented their plugin system.

GiteaMirror commented

@jolheiser commented on GitHub (Jun 28, 2022):

We could probably get some ideas on how mattermost have implemented their plugin system.

For posterity:
mattermost plugin package
It looks like they use go-plugin

@jolheiser commented on GitHub (Jun 28, 2022): > We could probably get some ideas on how mattermost have implemented their plugin system. For posterity: [mattermost plugin package](https://github.com/mattermost/mattermost-server/tree/master/plugin) It looks like they use [go-plugin](https://github.com/mattermost/mattermost-server/blob/5544e753e89d990ee87d63eae8082beb65ba0778/go.mod#L31)

GiteaMirror commented

@mscherer commented on GitHub (Aug 1, 2022):

Another inspiration could be woodpecker proposal around extensions https://github.com/woodpecker-ci/woodpecker/pull/915

@mscherer commented on GitHub (Aug 1, 2022): Another inspiration could be woodpecker proposal around extensions https://github.com/woodpecker-ci/woodpecker/pull/915

GiteaMirror commented

@Trendyne commented on GitHub (Aug 7, 2022):

Since nobody has mentioned it yet, projects like Adobe Lightroom, MPV, or Wireshark use Lua for this. You'd read and run Lua files from a directory where they would register events with callbacks or maybe return properties and functions. It's very light. simple, and fast but would make it very easy to make plugins and shouldn't be any harder to implement

Made up possible example:

-- Greet users on their first repo
gitea.on("newRepo", function(repo)
	if #repo.owner.repos == 1 then
		local msg = ("Welcome to our Gitea, %s!"):format(repo.owner.name)
		repo.owner:sendNotifacation(msg)
	end
end)

@Trendyne commented on GitHub (Aug 7, 2022): Since nobody has mentioned it yet, projects like Adobe Lightroom, MPV, or Wireshark use Lua for this. You'd read and run Lua files from a directory where they would register events with callbacks or maybe return properties and functions. It's very light. simple, and fast but would make it very easy to make plugins and shouldn't be any harder to implement Made up possible example: ```lua -- Greet users on their first repo gitea.on("newRepo", function(repo) if #repo.owner.repos == 1 then local msg = ("Welcome to our Gitea, %s!"):format(repo.owner.name) repo.owner:sendNotifacation(msg) end end) ```

GiteaMirror commented

@KN4CK3R commented on GitHub (Sep 26, 2022):

The Lua integration could be plugin too which forwards callbacks to Lua.

@KN4CK3R commented on GitHub (Sep 26, 2022): The Lua integration could be plugin too which forwards callbacks to Lua.

GiteaMirror commented

@Lord-Leonard commented on GitHub (Apr 24, 2024):

Are there any updates on this one? ^^

@Lord-Leonard commented on GitHub (Apr 24, 2024): Are there any updates on this one? ^^

GiteaMirror commented

@lunny commented on GitHub (Apr 25, 2024):

For most backend tasks, Gitea Actions can be considered as somewhat plugins.

@lunny commented on GitHub (Apr 25, 2024): For most backend tasks, Gitea Actions can be considered as somewhat plugins.

GiteaMirror commented

@Lord-Leonard commented on GitHub (Apr 25, 2024):

Yeah for my usecase the webhooks are sufficient. I will just have to host another small webserver alongside Gitea.
But it would have been nice to just write a plugin and call it a day :)

@Lord-Leonard commented on GitHub (Apr 25, 2024): Yeah for my usecase the webhooks are sufficient. I will just have to host another small webserver alongside Gitea. But it would have been nice to just write a plugin and call it a day :)

GiteaMirror commented

@Sharaf5 commented on GitHub (Aug 27, 2024):

Then there are 4 point of views could be considered for plugins

Compile directly inside source coed
RCP called via go-plugin
Gitea Actions can be considered as plugins
Webhooks

and I will add the 5th

APIs or Sockets with separate frontend from back "PWA Frontend"

@Sharaf5 commented on GitHub (Aug 27, 2024): Then there are 4 point of views could be considered for plugins - Compile directly inside source coed - RCP called via go-plugin - Gitea Actions can be considered as plugins - Webhooks and I will add the 5th - APIs or Sockets with separate frontend from back "PWA Frontend"

GiteaMirror commented

@lunny commented on GitHub (Mar 12, 2025):

Looks like Typescript 7 will be migrated to Go. So that maybe we can use typescript as the plugin language. https://github.com/microsoft/typescript-go

@lunny commented on GitHub (Mar 12, 2025): Looks like Typescript 7 will be migrated to Go. So that maybe we can use typescript as the plugin language. https://github.com/microsoft/typescript-go

GiteaMirror commented

2025-11-02 08:30:18 -06:00

@wxiaoguang commented on GitHub (Mar 12, 2025):

Looks like Typescript 7 will be migrated to Go. So that maybe we can use typescript as the plugin language. https://github.com/microsoft/typescript-go

typescript-go is just a TypeScript compiler implemented in Go with a LSP. Where do you see that "use typescript as the plugin"?

To be frank:

For the "plugin" proposal, I do not see anyone is really working on it, or whether it is feasible at current stage (my answer is "no": either gPRC or js/wasm/lua would involves a lot of work to design the structs and interfaces, no manpower).

Mission Impossible

So I would suggest to mark the proposal as "close as not planned" since it doesn't seem able to get real progress (reopen at any time when there is a feasible design and manpower)

For some existing requirements:

Frontend customization: include custom JS scripts into pages by "custom template"
Backend customization: webhook & API, or build from source with custom code

@wxiaoguang commented on GitHub (Mar 12, 2025): > Looks like Typescript 7 will be migrated to Go. So that maybe we can use typescript as the plugin language. https://github.com/microsoft/typescript-go `typescript-go` is just a TypeScript compiler implemented in Go with a LSP. Where do you see that "use typescript as the plugin"? ---- To be frank: For the "plugin" proposal, I do not see anyone is really working on it, or whether it is feasible at current stage (my answer is "no": either gPRC or js/wasm/lua would involves a lot of work to design the structs and interfaces, no manpower). **Mission Impossible** So I would suggest to mark the proposal as "close as not planned" since it doesn't seem able to get real progress (reopen at any time when there is a feasible design and manpower) For some existing requirements: * Frontend customization: include custom JS scripts into pages by "custom template" * Backend customization: webhook & API, or build from source with custom code

GiteaMirror commented

@wxiaoguang commented on GitHub (Apr 4, 2025):

Quote above: So I would suggest to mark the proposal as "close as not planned" since it doesn't seem able to get real progress (reopen at any time when there is a feasible design and manpower)

Golang eco-system is naturely not easy with plugins .... unfortunately.

@wxiaoguang commented on GitHub (Apr 4, 2025): Quote above: So I would suggest to mark the proposal as "close as not planned" since it doesn't seem able to get real progress (reopen at any time when there is a feasible design and manpower) Golang eco-system is naturely not easy with plugins .... unfortunately.

GiteaMirror commented

@hiifong commented on GitHub (Apr 4, 2025):

Maybe we can learn from git's plugin model, where commands that start with git- can be called freely by git, e.g. I have a git-bug plugin, and I can call my git-bug plugin by calling git bug.

@hiifong commented on GitHub (Apr 4, 2025): Maybe we can learn from git's plugin model, where commands that start with git- can be called freely by git, e.g. I have a git-bug plugin, and I can call my git-bug plugin by calling git bug.

GiteaMirror commented

@Sharaf5 commented on GitHub (Apr 5, 2025):

most top named Go/C/C++ projects support plugins including

CoreDNS : pre-compiled, selectively activated Go plugins
Traefik : Transpiling GO on the fly ( not recommended for performance ), and WASM ( may be considerd )
Nginx : pre-shared lib .so
PgSQL : plugable extensions ( citus, timescaleDB, ... )
WebHooks could be considerd a plugin mechanism for both front and backend
Blender, GIMP, VSCode, ... had plugin/estension systems

there were many success stories and a cost effective announce using plugins opening the way to be integrated into other projects
Really, closing it disappointed me, but hope this is in mind for future at least
I wished this project could grow beyond it's limit
hope you best luck

@Sharaf5 commented on GitHub (Apr 5, 2025): most top named Go/C/C++ projects support plugins including - CoreDNS : pre-compiled, selectively activated Go plugins - Traefik : Transpiling GO on the fly ( not recommended for performance ), and WASM ( may be considerd ) - Nginx : pre-shared lib `.so` - PgSQL : plugable extensions ( citus, timescaleDB, ... ) - WebHooks could be considerd a plugin mechanism for both front and backend - Blender, GIMP, VSCode, ... had plugin/estension systems there were many success stories and a cost effective announce using plugins opening the way to be integrated into other projects Really, closing it disappointed me, but hope this is in mind for future at least I wished this project could grow beyond it's limit hope you best luck

GiteaMirror commented

@wxiaoguang commented on GitHub (Apr 5, 2025):

most top named Go/C/C++ projects support plugins including

These examples you shown, are either desktop/traffic-server or C++ applications (Golang plugin doesn't work on Windows, but Gitea still needs to support), or the plugin doesn't need to heavily depend on the host application (traffic server: CoreDNS, Traefik). And either they have a large company & team, or a lot of active contributors to maintain.

For Gitea's plugin: Gitea itself is a heavy web application (but not a traffic server), there are more business logic than others, the proposed "Plugin Lifecycle" is already more complex than the traffic server examples. And Gitea community is not that large as others (that's what I meant "my answer is no: either gPRC or js/wasm/lua would involves a lot of work to design the structs and interfaces, no manpower").

WebHooks could be considerd a plugin mechanism for both front and backend

Actually it doesn't need a general plugin system, but you see that the webhook related PRs are still stale for long time (WIP: Custom Webhooks #19307). As simple as this one doesn't get success, how would a general plugin proposal succeed?

I don't want to disappoint anyone, but I think we need to face reality.

And see my comment above: reopen at any time when there is a feasible design and manpower

@wxiaoguang commented on GitHub (Apr 5, 2025): > most top named Go/C/C++ projects support plugins including These examples you shown, are either desktop/traffic-server or C++ applications (Golang plugin doesn't work on Windows, but Gitea still needs to support), or the plugin doesn't need to heavily depend on the host application (traffic server: CoreDNS, Traefik). And either they have a large company & team, or a lot of active contributors to maintain. For Gitea's plugin: Gitea itself is a heavy web application (but not a traffic server), there are more business logic than others, the proposed "Plugin Lifecycle" is already more complex than the traffic server examples. And Gitea community is not that large as others (that's what I meant "my answer is no: either gPRC or js/wasm/lua would involves a lot of work to design the structs and interfaces, no manpower"). ---- > WebHooks could be considerd a plugin mechanism for both front and backend Actually it doesn't need a general plugin system, but you see that the webhook related PRs are still stale for long time (WIP: Custom Webhooks #19307). As simple as this one doesn't get success, how would a general plugin proposal succeed? I don't want to disappoint anyone, but I think we need to face reality. And see my comment above: reopen at any time when there is a feasible design and manpower

GiteaMirror commented

@wxiaoguang commented on GitHub (Apr 5, 2025):

Let's keep it open and don't disappoint anyone. Let's hope there would be some real progresses.

@wxiaoguang commented on GitHub (Apr 5, 2025): Let's keep it open and don't disappoint anyone. Let's hope there would be some real progresses.

GiteaMirror commented