ocipkg

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.
- WIP: Optionally, support container signing in sigstore/cosign way.
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

bash 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:

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:

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.
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.
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.

License

This project is licensed under either of

Apache License, Version 2.0, (LICENSE-APACHE or https://www.apache.org/licenses/LICENSE-2.0)
MIT license (LICENSE-MIT or https://opensource.org/licenses/MIT)

at your option.