📦 suap

_{Just Shut Up And Package it, bloody hell mate...}

Warning

USER NOTICE: DO NOT use suap as a tool for building or installing cloudy-org applications, that is not the intent of the tool. For application setup / installation check the application's own instructions in it's README.md file.

Suap is in alpha testing stage at the moment, feel free to submit PRs to improve my shit Python code in this project. Thanks

Prerequisites:

Assuming you're on Linux (you don't need any of this for docker mode):

• NSIS (for packaging windows installers)
• Rust and Cargo (for packaging cargo projects).
  • x86_64-pc-windows-gnu (for building windows binaries)
• mingw-w64-binutils (required for embedding windows icons onto executables)

Packaging Usage

GitHub Workflow (CI)

# .github/workflows/suap.yml

name: Suap Package & Publish Binaries on Release Tag

# ... WIP, help wanted!

Warning

Suap is only designed for use in CI and Docker. You would only really want to use it during development for final testing.

Suap targets Python 3.13 and only supports Linux environments. The docker image also only supports x86_64.

Pip Install

python -m venv .venv
source .venv/bin/activate

pip install git+https://github.com/cloudy-org/suap@v0.1.0-beta.4

suap --help

UV Install

uv tool install --from git+https://github.com/cloudy-org/suap@v0.1.0-beta.4 suap

uvx suap --help

Now that the tool is installed in your environment, make sure you're inside your cloudy-org applications's directory with suap.toml at it's root.

If you don't have a suap.toml file, create one from the example here.

From here on you can query the help command for various actions you can perform other than packaging.

suap --help

Use Docker

By default suap runs it's commands in your environment. However your Linux environment is different to other user's Linux environments. For example an Arch Linux system is notorious for having newer glibc versions than Debian; this can cause problems when for example running an aarch64 binary compiled on an Arch system on a Raspberry Pi 4 running Debian.

Telling suap to run it's commands inside it's docker container helps solve such problems and improves reproducibility. The container also comes preinstalled with all necessary dependencies.

All you got to do is append a -d or --docker and suap will use the devgoldy/suap image:

suap -d package --project cargo --platform-format windows --platform-arch x86_64

Packaging

suap package --project cargo --platform-format windows --platform-arch x86_64

Project

In the future a suap project may have multiple types of projects under it so you must specify which type you're packaging via --project _{(at least for now)}.

Platform format

At this moment there are 3 platform formats you can package to:

• linux-bin (standalone binary)
• windows-bin (standalone binary)
• windows-setup (windows installer)

--platform-format {platform}-{format}

The windows platform format key is an umbrella key to build and package both formats windows-bin and windows-setup, the same way the linux key contains linux-bin.

Use the specific key (e.g: linux-bin) if you would like to target packaging just that format and not any other format under that platform.

Icons

In the suap.toml config we set the icons folder (icons = "./assets/icons"). We must populate that with icons for the application (be it placeholders or real official icons for prod):

# The icons folder is where you'll place your icons.
# 
# The name of the image files must be specific like so:
# "windows.ico" - windows specific app icon
# "original.png" - when there's no platform specific icon suap falls back to this
icons = "./assets/icons"

Here's an example:

Output

And here's me using suap to package windows binaries for roseate with the command from earlier:

The ./dist folder:

Readme Work In Progress...