Skip to content

Overview & Glossary

Jump to bottom
vgmoose edited this page Jan 25, 2023 · 6 revisions

Overview

Upon the creation of a Get object, the local repos.json is parsed from the config folder, and the packages from each remote repo are loaded over http(s) into memory.

If no repos.json file exists, a default one will be created. When packages are installed, updated, or deleted, the list of packages in memory is refreshed from every enabled repo again.

As of this time of writing, packages from different repos are simply both added, but in the future these packages should be merged.

For info on the repos.json local file syntax, see this .get/repos.json file.

Repos

The strictest definition of a repo is simply a http(s) URL that contains a repo.json file. For example, the Switch default repo URL is https://switch.cdn.fortheusers.org, and so the repo json is at /repo.json. Wii U's equivalent is here.

This contains a list of every package on the server. The layout is as follows:

{
    "packages": [ Package, Package, Package, Package, ... ]
}

Where Package's layout is defined in the next section.

The repo.json should not be manually maintained (although it can be), and instead should be configured using the repogen python script.

The other mandatory component of a repo is that it hosts package zips in the /zips/ folder.

Packages

Packages define a user-installable piece of content. They are zip files available within /zips/ from the repo's URL. Each Package object in the repo.json should coordinate with a name.zip file, where the name is the same as the field within the package.

Package layout:

{
    "category": "tool", 
    "updated": "04/04/2018", 
    "name": "pynx", 
    "license": "ISC License", 
    "author": "AileenLumina", 
    "url": "https://github.com/nx-python/Pynx", 
    "description": "Python on NX", 
    "title": "Pynx", 
    "version": "0.3.1-alpha", 
    "filesize": 6799, 
    "details": "A long description detailing what the package does", 
    "md5": "e33d3027c47ea7724a8efa9684ccac34"
}

These Package objects fill out the packages list in the Repo, detailed in the above section. All fields are optional except the name field. The only ones used internally by get at this time are: category, version, description, author, and title. Anything else can be added to be used by whatever web frontend you choose. (For instance, 4TU's HTML frontend).

Contents

A Package is presented to the user as something to be installed, updated, or deleted. The currently installed packages are tracked in the configuration directory within the .get/packages folder.

The package itself is from a zip located on the remote at /zips/name.zip. This zip should contain the exact file structure that should be unzipped into the local filesystem. For instance, the contents of a Switch homebrew usually goes in /switch/, however it may have additional resources that are somewhere else on the filesystem.

For instance, a tool may exist within the standard install location for apps, but store special data in another folder (such as customizable splash screen or something). As a result, the contents of the zip should be as follows:

/
├─ mytool
   └─ splash.png
└- switch
   └─ mytool
      ├─ custom_data.cfg
      └─ mytool.nro

However, in addition to the above data, there should also be two mandatory files that are also extracted from the zip:

  • manifest.install
  • info.json

These files should be in the root of the zip. The repogen script will automatically perform this step while generating the package zips. The layout and purpose of the manifests.install file is described below.

States

An installed package is considered to be out-of-date (and thus, an update available) when the version number of the package that the user currently has installed doesn't match the version number on the remote repo. Due to this, when updating your packages, you should make sure to bump the version number, otherwise it won't be presented to the user as a new update.

When a package is removed, the cached manifest is parsed to determine which files need to be deleted. It is then deleted from the configuration directory.

Manifests

For now, see this gist for the manifest.install file syntax. If one of these files does not exist while running the repogen script, one will be generated for every file in the package, with every file in the U: state.

In the above example, however, it may be useful to have a splash screen be in the G: state, so that it is only copied upon the first install. On updates, the file should not be overwritten (as the user may have replaced it with their own copy).

Example manifest.install file for the mytool app described in the above section:

G: mytool/splash.png
G: switch/mytool/custom_data.cfg
U: switch/mytool/mytool.nro

The first two files are marked G: , as they should only be modified when the app is first installed. The actual .nro (executable), however, is marked U: since it should be modified on every update.

Most apps should be able to work with these restricted characters. An unwanted scenario may occur if a change to one of the G: files is a breaking change (for example, the layout of the .cfg file changes). In this scenario, it is up to the app developer to not introduce breaking changes to files that aren't intended to be updated.

Package managers on the PC get around this problem by providing post- and pre- install scripts, but that isn't easily solved on the constrained type of environments that get runs in. In a breaking scenario, it may be up to the user to manually merge their data (or remove+install the app, rather than update).

Clone this wiki locally