Hello everyone,
I came up with a few ideas regarding the Plugin Manager which I assume is currently under planning/development.
As a plugin writer, I would like to have some kind of consistency for things like resources (translations) and data files, maybe even sound files. There should be a frontend (website) having all the plugin's source, resource, data, config and sound files layed out correctly for SP's folder structure - this would of course require quite of an amount of web space and thus donations from us all. But I think it would make things easier.
Plugin writers won't have to zip their plugins anymore or use GitHub, they would just create a plugin repo and upload their files - the frontend would then figure out the paths by analyzing the info.py file. It would just do on-the-fly zipping using Satoon's utility and then the zip will be deleted on a scheduled date. Maybe this could become some type of versioning system like GitHub, but more fine-tuned for the SP project.
What are your thoughts?
Note: if the idea gets rejected, I would love to contribute to the official plugin manager, aswell!
SP Plugin Manager thoughts
Re: SP Plugin Manager thoughts
Thank you for the suggestion. Work on SPPM has indeed already started, and is still a work in progress.
I don't think we want to create our own Version Control System or VCS host. There are already plenty of sites out there that do a tremendous job of this, and we don't really need to reinvent the wheel.
There is already a little bit of zip file validation written into the current SPPM, but more will be added at some point. Part of the validation is to make sure that only files of certain types are contained in specific directories. I started a topic related to this a while back:
viewtopic.php?f=10&t=186
Once we get a little further along, I will post about which file types can be in which directories, and we can all have a discussion around that. Of course, if, after we release SPPM, there are any file types that eventually need to be supported, it will be fairly easy to add them to SPPM's settings. The validation will notify the uploader about any files that are invalid for their type/directory, when uploading a zip that contains any invalid files.
I don't think we want to create our own Version Control System or VCS host. There are already plenty of sites out there that do a tremendous job of this, and we don't really need to reinvent the wheel.
There is already a little bit of zip file validation written into the current SPPM, but more will be added at some point. Part of the validation is to make sure that only files of certain types are contained in specific directories. I started a topic related to this a while back:
viewtopic.php?f=10&t=186
Once we get a little further along, I will post about which file types can be in which directories, and we can all have a discussion around that. Of course, if, after we release SPPM, there are any file types that eventually need to be supported, it will be fairly easy to add them to SPPM's settings. The validation will notify the uploader about any files that are invalid for their type/directory, when uploading a zip that contains any invalid files.
Re: SP Plugin Manager thoughts
So I believe that SPPM will only accept SRCDS files? No way to upload Flask directory in there too?
/id/its_iPlayer
My plugins: Map Cycle • Killstreaker • DeadChat • Infinite Jumping • TripMines • AdPurge • Bot Damage • PLRBots • Entity AntiSpam
Hail, Companion. [...] Hands to yourself, sneak thief.
My plugins: Map Cycle • Killstreaker • DeadChat • Infinite Jumping • TripMines • AdPurge • Bot Damage • PLRBots • Entity AntiSpam
Hail, Companion. [...] Hands to yourself, sneak thief.
Re: SP Plugin Manager thoughts
Currently, that is correct. It only supports plugins, sub-plugins, and custom packages.
Though, there is a requirements system that can handle those sorts of things. For instance, there can be a 'downloads' section in the requirements.ini file of a project that lists all extra downloads for the project:
Those items will be listed on the project's page under the Downloads section.
The idea is to allow all projects on SPPM be "sp install"-able. Since the Flask stuff doesn't really need to be installed on the game server itself, there would be no reason to allow that portion to be installable. Though, we could certainly consider adding another section that would not have all the zip file verification and would not be installable. My worry with that is that people will upload maps (and other types of files) that take up a lot of disk space. Actually, the same could be said for sounds and models, which we currently allow in the zip files.
Though, there is a requirements system that can handle those sorts of things. For instance, there can be a 'downloads' section in the requirements.ini file of a project that lists all extra downloads for the project:
Syntax: Select all
[downloads]
skins = "http://www.file-host.com/some_url/my_skins.zip"
[[maps]]
url = "http://www.file-host.com/some_url/my_maps.zip"
desc = "Extract all files from the zip into the server's ../maps/ directory."
Those items will be listed on the project's page under the Downloads section.
The idea is to allow all projects on SPPM be "sp install"-able. Since the Flask stuff doesn't really need to be installed on the game server itself, there would be no reason to allow that portion to be installable. Though, we could certainly consider adding another section that would not have all the zip file verification and would not be installable. My worry with that is that people will upload maps (and other types of files) that take up a lot of disk space. Actually, the same could be said for sounds and models, which we currently allow in the zip files.
Re: SP Plugin Manager thoughts
Yeah, reinventing the wheel is probably not the best idea. So, there will be a homepage like addons.eventscripts.com + "sp <sppm command>"?
I'm fine with that, too :)
Edit: I probably looked at it the wrong way. For zipping we could use something like "sp zip" or "sp release" which would be more useful than having it on the homepage, I think.
I'm fine with that, too :)
Edit: I probably looked at it the wrong way. For zipping we could use something like "sp zip" or "sp release" which would be more useful than having it on the homepage, I think.
Re: SP Plugin Manager thoughts
What about connecting SPPM with Github's "Releases" page? E.g. link particular plugin to, say, https://github.com/KirillMysnik/ArcRank/releases, so that the ZIP is not stored on SPPM but instead downloaded as the latest GH release?
Talking about disk space - well, the package size limit would be the way to go. Or implementing something like "the more w00t's you've got, the more space per plugin you have".
Talking about disk space - well, the package size limit would be the way to go. Or implementing something like "the more w00t's you've got, the more space per plugin you have".
/id/its_iPlayer
My plugins: Map Cycle • Killstreaker • DeadChat • Infinite Jumping • TripMines • AdPurge • Bot Damage • PLRBots • Entity AntiSpam
Hail, Companion. [...] Hands to yourself, sneak thief.
My plugins: Map Cycle • Killstreaker • DeadChat • Infinite Jumping • TripMines • AdPurge • Bot Damage • PLRBots • Entity AntiSpam
Hail, Companion. [...] Hands to yourself, sneak thief.
Re: SP Plugin Manager thoughts
iPlayer wrote:What about connecting SPPM with Github's "Releases" page? E.g. link particular plugin to, say, https://github.com/KirillMysnik/ArcRank/releases, so that the ZIP is not stored on SPPM but instead downloaded as the latest GH release?
That idea was presented to me by XE_ManUp a few months back. That is something we can consider for the long term, but for now, we want to get all the base functionality up and running. Actually, the idea XE_ManUp and I tossed around was having a GitHub web-hook so that anytime a new tag/release was added, it would automatically update the project to that version (on SPPM).
iPlayer wrote:Talking about disk space - well, the package size limit would be the way to go. Or implementing something like "the more w00t's you've got, the more space per plugin you have".
I don't like the idea of basing disk space off of rankings. A brand new project might be pretty massive, and have no ranking whatsoever. We will also keep all historical releases and not just throw one away as soon as a new one is uploaded. There probably will be a project size limit (per-release), but I am not sure what that will be.
Re: SP Plugin Manager thoughts
BackRaw wrote:Edit: I probably looked at it the wrong way. For zipping we could use something like "sp zip" or "sp release" which would be more useful than having it on the homepage, I think.
I'm not sure how feasible an "sp release" command would be. There are outlying directories that would need to be taken into account, as well as ignored files. For instance, GunGame has several directories that would need to be taken into account and several that would need to be ignored. It would be very difficult, without having to list all of them out in the command, or use a file that lists out added/ignored directories/files to accommodate this.
My PluginHelpers script doesn't fully take this all into consideration, yet, either. I do plan on updating it to utilize the file list within the git repository itself to know which files to add to the zip, but this still requires the project to be in its own directory and symbolically linked into SP and/or the server.
Re: SP Plugin Manager thoughts
satoon101 wrote:BackRaw wrote:Edit: I probably looked at it the wrong way. For zipping we could use something like "sp zip" or "sp release" which would be more useful than having it on the homepage, I think.
I'm not sure how feasible an "sp release" command would be. There are outlying directories that would need to be taken into account, as well as ignored files. For instance, GunGame has several directories that would need to be taken into account and several that would need to be ignored. It would be very difficult, without having to list all of them out in the command, or use a file that lists out added/ignored directories/files to accommodate this.
My PluginHelpers script doesn't fully take this all into consideration, yet, either. I do plan on updating it to utilize the file list within the git repository itself to know which files to add to the zip, but this still requires the project to be in its own directory and symbolically linked into SP and/or the server.
I'm sure we all will figure something out :)
Re: SP Plugin Manager thoughts
Just a note, but I have updated my PluginHelpers script to only add files to a release that are a part of the repository.
https://github.com/satoon101/PluginHelp ... 921009a805
I still want to make a video going over the setup steps. Hopefully I get time to do that fairly soon.
https://github.com/satoon101/PluginHelp ... 921009a805
I still want to make a video going over the setup steps. Hopefully I get time to do that fairly soon.
Return to “General Discussion”
Who is online
Users browsing this forum: No registered users and 14 guests