[reBane]

SPSauce is a plugin dependency fetchter and compile tool.

The main part is, going through a small list of dependencies you write, downloads SourceMod into a temporary directory and install/patch all dependencies over that installation.
This is not a tool to set up a server for you.

The dependencies can be pulled:

• Through the GitHub API
• Cloned with git (git needs to be installed)
• From the forums (threads or comments)
• Limetech (For asherkins stuff)

Note on forum dependencies: Please do not run mutliple scripts fetching forum dependencies at once, as that might trip the ddos protection of the forums and block further requests.

While building and releasing plugins is not the goal of this project, it is able to build plugins, zip them and attach them to GitHub releases.
It can also patch entries for the updater plugin and the plugin update checker csv.

I have an example GitHub Action set up to automatically build and attach archives to releases in this repository in case you want to check that out.

Due to issues with dependency side-loading in recent Java versions, I chagned the mechanism used for 1.5.0 (dev branch). I'm curious if it works for everyone else.

GitHub

[nosoop]

My understanding is that bundling / vendoring dependencies should be fine since the resulting output has to be GPLv3 anyways (so the dependencies have to have a GPLv3 forward-compatible license). Of course, this isn't legal advice.

In case you missed it, I do have some basic build tooling in the form of a project template that generates Ninja build scripts, which I use for rebuilding large projects. Definitely doesn't do any of the fancy dependency lookups that your tool appears to accomplish, though.

[reBane]

It seems your template / ninja is more concerned with the build itself, while I tried to automatically fetch dependencies / set up for compilation (with compiling as bonus). In that case the tools could even work together. For example with SPSauce pulling sourcemod and configure.py pointing to a relative compiler & include directory.

The License.txt talks about plugins, extensions and software built using sm, but idk if that applies to source code. Sure, it doesn't make sense to have a library and lock the include file behind some license, but I don't know people. (Not lawyer either, so no legal advice here)

License stuff aside I just like having a clean repo, and I think a tool like this could be a way to still provide other tools and developers with the means to get necessary deps to build the project.

[reBane]

I added a bunch of new stuff to SPSauce so I hopefully have to spend less time managing releases. I even managed to make it run through GitHub actions.

Values can be pulled from files using regex now (useful to get a plugins version), it can zip files, attach files to GitHub releases (and create the release), replace attached files on forum threads as long as CloudFlare lets it through, create and update Updater configs, and rewrite the table for Plugin Update Checker.
Oh also, for stuff that requires actual logic, like setting a variable to the current date, there now also lua script available. Even though the scripts should be in your control I didn't give it the io library and only a fraction of the os library.

[reBane]

For 1.5.0 (currently rc1) I detached the cache directory from the working directory. This should allow global installations if wanted, but requries the cache directory to be address with ${SPSCACHE} instead of simply specifying a subdirectory.
I also changed how dependencies are loaded to use a Launcher Agent. I hope this is compatible with apache and open installations and works for a wide range of Java versions, because loading dependencies instead of packing them is kindof a pain...

I will wait until I updated all my remaining projects to use 1.5.0-rc1 before marking it a stable release tho.