[Feature]: Maintain plugins by repo

[aooohan]

1. Your usage scenarios?

Currently, the plugin installation is based on the http protocol fetch. The limitations are as follows:

1. Only supports loading a single lua file, which lead to us not use any third party library if we want to require in plugin.
2. There is no place for plugin introductions. For example, maybe the plugin might allow configuring some environment variables. Like [Feature]: Support customized mirror #89. There is currently nowhere to tell the user how to use this variable, if it exists.

2. What is your expected outcome?

Adopt git protocol as plug-in distribution protocol

[bytemain]

1. I think it can be one of the installation methods, but not all plugins should switch to git
2. personally, I didn't like the git way to download extension, for example, user need to install git, configure git proxy, has a unused .git folder

I prefer the plugin publish mechanism we currently used, I want a way install plugin such like npm registry, multiple lua file can be bundle into a zip file, and every plugin has a metadata file, we define version in the metadata file

[aooohan]

I think it can be one of the installation methods, but not all plugins should switch to git

Yes, I mean as one of the ways, not as the only way.

personally, I didn't like the git way to download extension, for example, user need to install git, configure git proxy, has a unused .git folder

Even so, but through git way we can place a readme for introduction, which can be displayed by gitee or github.

I prefer the plugin publish mechanism we currently used, I want a way install plugin such like npm registry, multiple lua file can be bundle into a zip file.

But how do we distribute zip files?

[bytemain]

Sure, I agree that we should add a way to install plugins via github repo, and github repo has many advantages, it also can use github release to publish versions.

[bytemain]

I am just think currently install mechanism is simple and enough, I think we can use github as another installation method called git, currently we used is http.

I think the http method can extends the power of this index.json

for example, it can define a new field called files, so we can download multiple files now.

[aooohan]

I am just think currently install mechanism is simple and enough

Agree, I think so.

I think the http method can extends the power of this index.json
for example, it can define a new field called files, so we can download multiple files now.

Good point.

If it is maintained by us, we can do this to solve the problem of multiple files. But what if it is a plug-in maintained by the user? I ask this because I feel that if the later plug-ins are maintained by vfox maintainers, the workload will be huge. If we still use http, how to solve this problem?

[bytemain]

the workload will be huge

seems #92 (reply in thread) is a good choice

[fangzhengjin]

such as this?
https://github.com/cxfksword/jellyfin-plugin-metashark/releases/tag/manifest
pin releases manifest
github actions cron update this assets

[aooohan]

Wow, thanks, that looks like the solution I was looking for, let me take a closer look.

[aooohan]

I took a complete look at the solution based on #92 (comment). It can solve the two problems I mentioned, and it also makes it easier for users to maintain their repo.

1. Expand on index.json according to this solution, as [Feature]: Maintain plugins by repo #92 (reply in thread) mentioned.
2. Provide a plugin template repo, which contains the basic directory and json file, and provide a github action to help complete the release.

What do you think? @bytemain ;)

[aooohan]

If it is not concentrated management, it looks more like brew tap.

Yes! But then vfox would have to introduce go-git to make sure, that the git functionality is there. Or clearly indicate that vfox depends on git, I don’t like this ;)

[bytemain]

looks good to me, the plugin upload all its need to github release, and we can download them in vfox

[fangzhengjin]

In this case, it may become:
vfox manifest add [reponame] [https://xxxxx/manifest.json]

[aooohan]

In this case, it may become:
vfox manifest add [reponame] [https://xxxxx/manifest.json]

No, we can still maintain the style quo.

vfox add -s https://xxxxx/manifest.json and vfox add category/name.

We can also maintain our own core repository, just like https://github.com/Homebrew/homebrew-core.

Users can submit their manifest to us through PR.

[fangzhengjin]

vfox add category/name

This method may also require the user to configure the proxy address to access it.
such as: vfox add category/name --mirror https://mirror.ghproxy.com/https://github.com/version-fox/vfox-plugins

[bytemain]

@aooohan is there anything I can do for this? do we have any process about this

[aooohan]

Thanks for wanting to help. ;)

see #112

This is just part of it, I will continue to expand it later. You can pick one that interests you.