Package Uploads Client

Also known as the "Package Uploader Client".

Part of the Package Client Toolset (see "pkgu.eagle" and "pkgr_upload.eagle").

View preliminary documentation for version 1 of the Package Client Toolset

The Package Uploads Client is used to upload new packages.

It works in both Tcl/Tk and Eagle.

It has an interactive user interface (using Tk or WinForms).

It shares code with the Package Repository Client and Package Downloads Client.

Roughly, at a high level, it does the following:

1. Accepts an API key, package name, package patch level, target language, target language version, target platform, and a list of file names, either via the command line or interactively.
2. Makes sure that the command line executables are installed for both GPG2 and Fossil.
3. Stages (adds and signs) the specified list of package files to the associated local checkout of the package file repository (see: "https://pkg.management/pkgd ").
4. Attempts to commits the package files, always on a new branch.
5. Creates a script block to download the files using the Package Downloads Client, locked to the specific checked-in version.
6. Signs the created script block.
7. Submits the package metadata to the package repository server (see: "https://pkg.management/pkgr ").

Prior to being able to make use of it, the following prerequisites must be met:

1. API keys must be created by an administrator of the Package Repository Server.
2. A Fossil login must be created by an administrator of the Package Downloads Server.
3. GPG ("gpg2") must be installed somewhere along the executable search PATH.
4. The Fossil binary must be installed somewhere along the executable search PATH.
5. The Package Downloads Server repository must be cloned and opened.

Prior to being able to publish trusted packages, the following prerequisites must be met:

1. The public key for the package maintainer must be added to the key ring trusted by the Package Client Toolset.

Other important things to note:

1. The Package Uploads Client currently assumes that all files for a particular package will reside in the same directory.
2. The directory immediately containing all the package files is the one that will end up being added to the Package File Server repository.
3. Packages are (currently) always submitted to a new branch (branched off of "trunk" in production -OR- "testing" in the dedicated test instance).
4. The script block submitted to the Package Repository Server always uses the check-in identifier; therefore, the branch does not matter.

Also see

• Package Repository Client
• Package Repository Server
• Package Downloads Client
• Package Downloads Server

This project is sponsored by Eyrie Solutions.

The list of administrators is currently: Joe Mistachkin

More details to follow.