Proposal: Switch to a URL-like Dependency String Format

[Southclaws]

Most of the current main complaints are among:

• Loading arbitrary .so/.dll plugins without the need for package definitions and GitHub
• Filterscripts

There have been quite a few issues that have attempted to propose solutions for these already. @ADRFranklin has poited out in the past that some of these additions result in storing data in multiple places.

Problem Background

The main issue with plugins is if a user wants to use a plugin that has not been configured for sampctl on GitHub with a pawn.json etc. (I'll call these "Unregistered Plugins" from hereon), the user must add the filename (minus the extension) to the runtime.plugins array. This is a bit of a hack, that array is actually used internally (pawn.json reflects internal data structures 1:1) which is where the dependency resolution engine will add plugin files that dependencies "provide" via their GitHub releases page.

This works fine until plugin order became a concern, there was no simple way to solve this. It basically came down to:

1. Insert the dependency-provided plugins before the existing items
2. Append the dependency-provided plugins after the existing items
   Both of which caused issues.

There was another proposal to add a prefix to dependencies that would allow the specification of order, but this would mean adding that syntax to both dependencies and runtime.plugins (and probably devDependencies too). This seemed like a bad approach since both those fields have different semantics and different internals, which would mean duplication of the some of the parsing code.

This issue proposes what I think to be the best solution so far: URL-Like dependency strings.

URL-Like Dependency Strings

Dependency strings currently have the following format:

• user/repository[:version]|[@branch]|[#commit]

Or, alternatively, a Git SSH string:

• [email protected]:user/repository[:version]|[@branch]|[#commit]

This proposal aims to modify only the first of these, and also only in an additive way, for backwards compatibility. A user/repo[version constraint] will default to a GitHub repository as normal.

However, the addition of an optional scheme to the path would turn the user/repo part into a fully valid URL. This would permit a set of custom schemes to be defined within sampctl which would allow the addition of a number of alternative sources for dependencies:

• filterscript://southclaws/samp-object-loader would facilitate filterscripts-as-dependencies
• plugin://plugins/some-custom-plugin would read a plugin from the path component of the URL and add it to the runtime.plugins list internally, in the correct position in the list (i.e. before any dependency-provided plugins that were added after in the dependencies list).
• includes://legacy would add the directory ./legacy to the pawncc includes list, without the need to modify builds (which would of course still be possible).

The addition of schemes to dependency strings would provide many more ways to declare required resources for both the build and run processes, all in a single place.

Full example:

{
  "repo": "samp-library",
  "user": "Southclaws",
  "dependencies": [
    "plugin://plugins/SKY",
    "includes://legacy",
    "Zeex/samp-plugin-crashdetect",
    "Southclaws/zcmd"
  ]
}

Which would:

• Add the custom SKY plugin before crashdetect
• Add legacy as an include path before crashdetect and zcmd
• Add crashdetect resource as an include directory
• Add crashdetect as a plugin after custom SKY
• Add zcmd dependency directory as an include directory

I feel like this is the simplest solution that fits into the current data model, is backwards compatible and actually reduces the number of fields a user needs to modify in a pawn.json file.

If/when this is implemented, a user should never need to touch runtime.plugins or builds.[].includes.

Please leave feedback to this proposal in this issue thread, hopefully this will make it into the next release and maybe just maybe I will bump the version to 1.9.0 finally and touch up some other things and clean up some messy bits of code and user experience!