Package

Overview

The Swamp compiler includes a package manager called Sprout, used for downloading packages.

How to create a package

You must have a separate (git) repository for each package you publish.

Repository names must use lowercase snake_case: lowercase letters, digits, and underscores (_). They must start with a lowercase letter and be at least three characters long.

Create a swamp.yini at the repository root:

It should contain name, description, license (spdx), version, license, type, edition, src_dir (typically pointing to “src/”), asset_dir (if you use it) and any dependencies needed.

name: package_name
version: "0.1.2" # this should match your released version (no `v` prefix)
description: Some short description on what the package does
license: MIT  # must be a SPDX license
type: :lib

edition: 2026 # the Swamp language edition

src_dir: src/
assets_dir: assets/ # optional if you don't have assets

# dependencies are optional if you don't need it
dependencies: {
    lily: "0.3.40"
}

It should have at least a src/lib.sw. If you have more modules, they should be imported in the lib.sw file (e.g. mod some_other_module)

Packages must include a license file whose name starts with LICENSE. Examples: LICENSE,LICENSE.md,LICENSE.txt,LICENSE-MIT

We encourage the use of a permissive open source license such as MIT, BSD-2-Clause, or BSD-3-Clause.

It is recommended to include a README.md to give more information.

If you include docs, please add them to a docs/ directory and use markdown files.

Example tree structure

.
├── swamp.yini
├── README.md
├── LICENSE
├── src/
│   └── lib.sw
└── assets/

Test your package with swamp build.

Upload it to a supported hosting service.

Currently sprout supports:

• Codeberg
• GitHub

Experimental support:

• GitLab
• Bitbucket

Make sure you annotate your releases with semantic versioning prefixed by v. example: v0.1.2.

to annotate in git:

git tag -a v0.1.2 -m "v0.1.2"

then push it to the origin (the hosting service):

git push origin --tags

Remember: You should not remove a tagged version, since that will impact users of that version.

How to use your package

In the program or library that consumes it:

dependencies: {
    package_name: { repo: "codeberg:user_name/package_name", version: "0.1.2" }
}