lip install

Install packages.

Synopsis

lip install <PACKAGES> [options]

Arguments

Each package argument takes one of the following forms:

1. Repository — <path> or <path>#<variant> (e.g. github.com/user/repo): the git repository https://<path>.git, newest version first.
2. Repository with version — <path>@<version> or <path>#<variant>@<version> (e.g. github.com/user/repo#lua@1.0.0): exactly that version, the commit of the tag v<version>. The version is a SemVer 2.0.0 version without the leading v. Like a git ref, it pins the package: see Git refs.
3. Repository with a git ref — <path>[#<variant>]@branch:<branch>, @tag:<tag> or @rev:<commit> (e.g. github.com/user/repo@branch:main): the commit that the branch head, the tag or the commit id names, whatever its version. Any branch or tag name is accepted, not only v<SemVer> tags; a commit id must be the full 40 hexadecimal digits. See Git refs.
4. URL — an https:// URL of a ZIP file (e.g. https://example.com/package.zip), optionally followed by #<variant>. Other schemes, such as http:// and file://, are not accepted.
5. Local path — a ZIP file or a directory on your disk, by an absolute path or a path relative to the current directory (e.g. ./package.zip, C:\Downloads\package.zip or ../MyTool), optionally followed by #<variant>. An argument is local when it starts with ./, ../, .\ or ..\, is . or .., is an absolute path, or contains no @ and either ends with .zip (ignoring case) or names an existing file or directory. A local file must be a ZIP archive, whatever its name; a local directory is taken as the archive of its contents.

A repository path without / is a repository of LiteLDev: LeviLamina@26.60.6 is short for github.com/LiteLDev/LeviLamina@26.60.6, and LegacyScriptEngine#lua for github.com/LiteLDev/LegacyScriptEngine#lua.

Every package must have a lip.toml at its root (see lip.toml) with an entry of the requested variant for the side and platform of the workspace.

In a workspace that has no game yet, set up the server first with lip setup, or install LeviLamina or the server itself, which sets it up (see The Game and the Loader).

The dependencies of the packages are installed too. Installing a package that is already explicitly installed is an error; use lip update to change its version. Two arguments that name the same identity are an error too. A package that is installed as a dependency becomes explicitly installed, keeping its version when that version satisfies the argument.

Git refs

A git ref pins a repository to one commit:

• @<version> takes the commit of the tag v<version>. lip update keeps that version.
• @branch:<branch> takes the head of the branch now. lip update follows the branch to its new head.
• @tag:<tag> takes the commit the tag points to; any tag name works, e.g. @tag:nightly. lip update resolves the tag again.
• @rev:<commit> takes exactly that commit, which never changes. Abbreviated commit ids are not accepted, since resolving them would need the whole history of the repository.

The version of a package installed this way is the version that its lip.toml declares at that commit. Only a tag named v<SemVer>, such as @tag:v1.2.0, gives the package the tag's version, as for plain versions: the lip.toml there must declare that version (a tooth.json of an earlier format takes the tag's version). The state file records the source, the commit it resolved to and its package file, so the workspace keeps that commit until you update.

A package installed from a git ref also satisfies dependencies on its package id and variant without a git ref, as long as its version is in the dependency's range and the repository has a version tag that lip could install for the dependency: a mod requiring github.com/user/lib >=1.5.0 accepts a github.com/user/lib installed from @branch:main that declares 1.6.0, and fails if it declares 1.4.0, or if no version tag of github.com/user/lib is 1.5.0 or higher.

Platforms

lip installs the entries for the side server and the platform win-x64, the platform of every workspace environment, whatever system lip runs on: on Linux and macOS too, lip installs the packages of the Windows server and runs it, and the hooks of its packages, through Wine, unless you set up the Linux server (see Running a Server).

The Game and the Loader

The server of a workspace is its game, the installed package of github.com/LiteLDev/bds, with its loader, the installed package of github.com/LiteLDev/LeviLamina, or without a loader. lip setup chooses them.

In a workspace that has no game, installing a mod, or a package that would install LeviLamina or the server as a dependency, fails and points to lip setup.

An argument that names LeviLamina, github.com/LiteLDev/LeviLamina without a git ref or with @<version>, or the server, github.com/LiteLDev/bds or github.com/LiteLDev/bds#linux, without a git ref or with @<version>, makes lip install a lip setup, carried out together with the other arguments in the same operation:

• Build: linux when the server is named as github.com/LiteLDev/bds#linux, and windows otherwise.
• Loader: LeviLamina when an argument names it, at the version it gives; without a version, the newest LeviLamina that supports the game version the server argument gives, or the newest LeviLamina when no argument gives a game version. No loader when no argument names LeviLamina.
• Game version: the version the server argument gives; without one, the newest version of the server that the dependency of that LeviLamina on github.com/LiteLDev/bds accepts, or the newest version of the server when no argument names LeviLamina.

So lip install LeviLamina sets up the newest LeviLamina with the newest game it supports, lip install LeviLamina@<version> that version of LeviLamina with the newest game it supports, and lip install github.com/LiteLDev/bds#linux@<version> the Linux server of that version, without a loader. Two arguments that name the server, or two that name LeviLamina, are an error. As for lip setup, lip asks you to accept the Minecraft EULA before it downloads the game (see The Minecraft EULA); give --accept-eula in a script.

Otherwise, lip install never installs, uninstalls or replaces the game or the loader. When the packages cannot be installed with them as they are, e.g. when a mod needs a newer LeviLamina, the command fails, naming the game version and the version of LeviLamina, and lip setup: set up a game and a loader that the mod supports with lip setup, then install the mod.

The Server

github.com/LiteLDev/bds, the Bedrock Dedicated Server, has three variants: the default variant and windows install the Windows server, and linux installs the Linux server. A workspace holds only one of them, its game, set up by lip setup (--build linux for the Linux server), or by lip install as described above:

lip install github.com/LiteLDev/bds#linux

lip makes bedrock_server of the Linux server executable itself. lip run starts the Linux server on Linux on x64; see Running a Server.

Options

Examples

lip install LeviLamina
lip install LeviLamina@26.60.6 --accept-eula
lip install github.com/LiteLDev/bds#linux
lip install github.com/LiteLDev/LegacyScriptEngine#lua
lip install github.com/user/repo@1.0.0
lip install github.com/user/repo@branch:main
lip install github.com/user/repo@tag:v1.0.0
lip install https://example.com/package.zip
lip install ./package.zip
lip install ../MyTool