Wildstar Addon Package Manager Project

wildstar
pc

#1

Didn’t know whether this should be in meta or wildstar, but here we go!

Looking for feedback and of course: “would you actually use a tool like this?”

Wildstar Addons in Git + Package Manager

The basic gist of my idea is that instead of users going to Curse or wherever and looking for addons, I had the idea of moving existing addons into a Github or Bitbucket organization (example organization )

Besides just being in source control, you now get the added bonus of giving players the ability to pull new updates to their addons in a much more streamlined fashion. Not to mention access to the awesome github API.

This project would be split up into a few components listed below. Some of this will get mildly technical.

Indexer

Some process would sit and watch http://www.curse.com/ws-addons/wildstar and occasionally parse the addon list.

When a new addon is encountered:

  1. The .zip is downloaded from curse
  2. Extract to a temporary location
  3. Create a new repository in our organization.
  4. git init; git commit -am "initial commit" and push that bad boy to the new remote repo.
  5. Maybe index data about the repo (name, sha, tags, etc) in a DB

When an existing addon is encountered, lets update it:

  1. The .zip is downloaded from curse
  2. Extract to a temporary location
  3. git clone; the matching repo from our organization
  4. Force cp from the zip temp location to the git repo directory
  5. . git commit -am "updating {$repo_name} from curse" and push that bad boy.

Package Index/API

This would just be a simple web service that acts a middle man between the client/package manager and our package metadata (from the DB and github)

The package manager makes requests to these API endpoints:

GET /api/:api_version/package/:package_name

{
  "name": "Nameplates",
  "description": " ... ",
  "version_sha": "87cvn87c6",
  "remote_url": "https://github.com/blah blah"
}

GET /api/:api_version/package/search?q=":query"

[
    {
      "name": "Nameplates",
      "description": " ... ",
      "version_sha": "87cvn87c6",
      "remote_url": "https://github.com/blah blah"
    },
    {
      "name": "Cool Plates 2",
      "description": " ... ",
      "version_sha": "98xbc6",
      "remote_url": "https://github.com/blah blah"
    }
]

A simple HTML version of all packages would also be provided (maybe running separately querying the API).

Package Manger

If the above stuff didn’t make sense, this component should. It’s the piece that the actual player will use to update and install their addons.

The following examples are given in a common CLI style. You could imagine the same actions occurring in a GUI with buttons etc. I’m just going to step through the operations.

wap == Wildstar Addon PackageManager

> wap install bijiplates

  1. A request is made to the Package Index to GET the package information.
  2. Assuming it is found, the the new version will be downloaded from the remote repository into the user’s addon directory.
  3. Some metadata will be saved in a local config file saving the full path of the addon and the sha downloaded.

> wap upgrade bijiplates

  1. A request is made to the Package Index to GET the package information.
  2. Local current saved sha is compared against the remote.
  3. If remote is newer, go through the install process again.

Not providing a name argument here will upgrade everything

> wap uninstall bijiplates

Deletes that sumbitch.

> wap list

Lists all known remote addons

> wap search query

Searches the package index for an addon

GUI/Toolset for package manager

I am a big noob when it comes to Windows dev. I prefer me a *nix terminal, a good package repo and a decent scripting language. So I wanted to try this a little differently. The goal being complete portability.

pypy is portable on windows!. This means the user doesn’t have to install anything, python can be shipped with the project. Maybe java would also be good here because most windows users probably have java installed.

libs would be written in python. The GUI could be a local flask instance! This would be very interesting because the client and the HTML package index could be pretty much the same exact thing.

Conclusion

This is more of a project spec than anything :smile: but as I was typing that’s what spewed out. After getting to the end of this it still does not seem that crazy to me. I was figuring i’d type out the idea and realize it was shit. So that’s a good first test.


#2

Bump. It did not look like you got the feedback you were looking for…anyway you could add a quick and easy dumbed down statement for guys like me? Also if you would like I could cross post this for you and give you a wider audience.