ocipkg 0.1.0

OCI registry for package distribution
Documentation

ocipkg

crate docs.rs master

OCI Registry for package distribution.

Features

  • You can distribute your binary including static or shared library through OCI registry (e.g. GitHub Container Registry) by your own authority.
  • Users can download your binary without container runtime (e.g. docker or podman).
  • Binaries are stored in local file system (typically under $XDG_DATA_HOME/ocipkg) with image name and tags, and safely shared by several local projects.
  • Integration to linking libraries. Users can link same library specified by image name and tag everywhere.

Examples

Library type Create package in Rust Use package from Rust
static examples/static/rust/lib examples/static/rust/exe
dynamic examples/dynamic/rust/lib examples/dynamic/rust/exe

CLI tools

Install

cargo install --features=cli ocipkg@0.1.0-rc.0

ocipkg command

TBW

cargo-ocipkg command

A tool for creating and publishing container using library built by cargo build.

$ cargo ocipkg build --release
    Finished release [optimized] target(s) in 0.00s
    Creating oci-archive (/home/teramura/github.com/termoshtt/ocipkg/examples/dynamic/rust/lib/target/release/ocipkg_dd0c7a812fd0fcbc.tar)

The filename is in form of ocipkg_{{ hash }}.tar, and this hash is calculated from image name and Cargo.toml.

Container image name is determined using git commit hash as {{ registry }}:$(git rev-parse HEAD --short) where registry name is set by Cargo.toml:

[package.metadata.ocipkg]
registry = "ghcr.io/termoshtt/ocipkg/dynamic/rust"

This container can be published by cargo-ocipkg publish:

$ cargo ocipkg publish --release
     Publish container (ghcr.io/termoshtt/ocipkg/dynamic/rust:be7f108)

Why ocipkg?

I have determined to start this project while writing FFI crate in Rust. The problem is "how to get a share/static library linked to FFI crate". This is the problem bothered me and prevent from creating portable C++ library.

We have three options:

  1. Use library in the system
    • ✔ Library is prepared by the system administrator who would be most familiar with the system.
    • ❌ Developer have to know how the library is distributed in user's system, possibly Ubuntu 22.04, 20.04, 18.04, Debian sid, 11, 10, 9, RHEL9, 8, 7, ArchLinux, Gentoo Linux, NixOS, FreeBSD, macOS with brew, Windows with winget, chocolatey, scoop, ...
    • ❌ Some system does not allows co-existence of multi-version libraries.
    • Most of *-sys crate support this option.
  2. Get source code from the internet, and build and link them
    • ✔ Developer can control the library fully.
    • ❌ Development tool, e.g. cmake, is required in user system, and requires additional build resources.
    • Some crate support this option, and they are named with *-src.
  3. Get compiled library from the internet on build time
    • ✔ Developer can control the library fully, too.
    • ❌ Requires HTTP(or other protocol) server to distribute the library
    • ❌ Developer have to ready binaries for every supported platforms, e.g. x86_64-unknown-linux-gnu, x86_64-pc-windows-msvc, aarch64-unknown-linux-gnu,...

ocipkg focuses on 3., i.e. helping distributing binary compiled by the developer through OCI registry.

Links

Open Container Initiative (OCI) is a project under Linux Foundation.

The idea that distribute binary files (not a system image) using OCI registry is based on ORAS.

Similar projects trying to distribute packages using OCI registries:

License

© 2020 Toshiki Teramura (@termoshtt)

This project is licensed under either of

at your option.