multi-backend declarative package manager
metapac allows you to maintain a consistent set of packages across
multiple machines. It also makes setting up a new system with your
preferred packages from your preferred package managers much easier.
cargo install metapacparu -S metapacmetapac is a meta package manager, that means it does not directly
implement the functionality to install packages on your system, instead it
provides a standardised interface for installing packages from other
package managers. See the Supported Backends section
for a list of the currently supported backend package managers.
metapac is also a declarative package manager, that means that you
declare in .toml group files the packages you would like installed on
your system and then run one of the metapac commands which read these
group files and then operate on your system to do some function such as
install packages in your group files that are not present on your system
yet (metapac sync), or remove packages present on your system but not in
your group files (metapac clean).
The group files are then stored with your other system configuration files and so can be tracked with version control.
By default all backends are disabled. Enable the backends you want
metapac to manage by adding them to the enabled_backends config in
metapac's config file. See the Config section for more
details.
Run metapac unmanaged and save the output into a group file in
metapac's groups/ folder, see the Group Files
section for the exact location of this folder on your operating system.
For example, on linux this would mean:
mkdir -p ~/.config/metapac/groups
metapac unmanaged > ~/.config/metapac/groups/all.tomlNow metapac won't try to remove any of your explicitly installed packages
when you run metapac clean.
Caution
If you run metapac clean without first configuring your group files
with the packages you want installed then metapac will attempt to
remove all of your packages from your enabled_backends.
metapac clean will always show you which packages it intends to remove
and ask for confirmation, so make sure to double check that the expected
packages are being removed before confirming.
- Edit your group files with a text editor to add the package to an
existing group file or create a new group file and add the package to
it. See the
Group Filessection for the group file syntax - Run the
metapac addcommand, seemetapac add --helpfor arguments - Run the
metapac installcommand, seemetapac install --helpfor arguments
After the first two options you will then need to run metapac sync for
the newly added package to be installed, whereas for metapac install it
also installs the package while adding it to a group file.
Tip
The first option is recommended since then you can group or organize the
order of packages in your group files in a way that is meaningful to you
and even add comments using the toml format.
Do the opposite of Adding a new package. The
opposite of metapac add is metapac remove, the opposite of metapac install is metapac uninstall and the opposite of metapac sync is
metapac clean.
Hooks are commands that you can add per-package in your group files. They
get run by metapac at various stages in some of metapac's commands.
One of the main use-case is to allow you to declaratively maintain your
enabled systemd services alongside each package in your group files. See
the Group Files section for some examples.
before_install: Run before a package is installed. Only applies to themetapac synccommand.after_install: Run after a package is installed. Only applies to themetapac synccommand.before_sync: Run before installing any packages, regardless of whether the package is already installed or not. Only applies to themetapac synccommand.after_sync: Run after installing all packages, regardless of whether the package was already installed or not. Only applies to themetapac synccommand.
For more advanced usage read through the remaining sections, especially the
Config section. You can also run metapac --help to get a
list of all of the available commands.
At the moment, these are the supported backends. Pull requests and issues for additional backends are always welcome!
| Backend |
|---|
arch |
apt |
brew |
bun |
cargo |
dnf |
flatpak |
npm |
pipx |
pnpm |
scoop |
snap |
uv |
vscode |
winget |
xbps |
yarn |
Arch has two special types of packages called meta packages and package
groups. (See
https://wiki.archlinux.org/title/Meta_package_and_package_group).
metapac only supports meta packages in group files since they are "real"
packages whereas groups are not "real". This is because meta packages are
normal PKGBUILD files with no content of themselves but which have several
dependencies, whereas package groups are special cases that don't have a
corresponding PKGBUILD file. For example, running pacman -Si nerd-fonts
returns "error: package 'nerd-fonts' was not found".
If you still want the behavior of a meta package you have two options.
Firstly, consider creating your own meta package with the same packages as
the group. Consider also publishing this package to the AUR so other users
can also benefit from it. Convention has it that meta packages end in
-meta, for example, the meta package version of nerd-fonts might be
called nerd-fonts-meta (Although nerd-fonts-meta does not yet exist at
the time of writing, 2025-09-03).
Alternatively, you could create a new group file using the packages from
the package group, which you can get from the command: pacman -Sgq <group_name>.
If on linux you might need to first run npm config set prefix ~/.local.
You might need to first run pnpm setup.
scoop doesn't differentiate between implicit and explicit packages.
Therefore, you will need to list all packages and their dependencies in
your group files. See
ScoopInstaller/Scoop#4276.
# metapac's config.toml file (like this one) should be placed in the following location
# dependent on the operating system as specified in the `dirs` crate:
# | Platform | Value | Example |
# | -------- | ----------------------------------------------------- | ------------------------------------------------------------ |
# | Linux | $XDG_CONFIG_HOME or $HOME/.config/metapac/config.toml | /home/alice/.config/metapac/config.toml |
# | macOS | $HOME/Library/Application Support/metapac/config.toml | /Users/Alice/Library/Application Support/metapac/config.toml |
# | Windows | {FOLDERID_RoamingAppData}\metapac\config.toml | C:\Users\Alice\AppData\Roaming\metapac\config.toml |
# Backends to enable for most of metapac's behavior. See the README.md or
# run `metapac backends` for the list of backend names
# Default: []
enabled_backends = ["arch"]
# Whether to use the [hostname_groups] config table to decide which
# group files to use or to use all files in the groups folder.
# Default: false
hostname_groups_enabled = true
# Which group files apply for which hostnames
# paths starting without a / are relative to the groups folder
# Default: None
[hostname_groups]
pc = ["example_group"]
laptop = ["example_group"]
server = ["example_group"]
[arch]
# Since pacman, pamac, paru, pikaur and yay all operate on the same package database
# they are mutually exclusive and so you must pick which one you want
# metapac to use.
# Must be one of: ["pacman", "pamac", "paru", "pikaur", "yay"]
# Default: "pacman"
package_manager = "paru"
[cargo]
# Whether to default to installing cargo packages with the --locked option.
# Default: false
locked = true
[flatpak]
# Whether to default to installing flatpak packages systemwide or for the
# current user. This setting can be overridden on a per-package basis.
# Default: true
systemwide = true
[vscode]
# Since VSCode and VSCodium both operate on the same package database
# they are mutually exclusive and so you must pick which one you want
# metapac to use.
# Must be one of: ["code", "codium"]
# Default: "code"
variant = "code"# metapac's group files (like this one) should be placed in the following location
# dependent on the operating system as specified in the `dirs` crate:
# | Platform | Value | Example |
# | -------- | ----------------------------------------- | -------------------------------------------------------- |
# | Linux | $XDG_CONFIG_HOME or $HOME/.config/groups/ | /home/alice/.config/metapac/groups/ |
# | macOS | $HOME/Library/Application Support/groups/ | /Users/Alice/Library/Application Support/metapac/groups/ |
# | Windows | {FOLDERID_RoamingAppData}\groups\ | C:\Users\Alice\AppData\Roaming\metapac\groups\ |
#
# The packages for each backend in group files can come in two formats, short-form
# and long-form:
#
# short-form syntax is simply a string of the name of the package.
#
# long-form syntax is a table which contains several fields which can
# optionally be set to specify install options on a per-package basis.
# The "package" field in the table specifies the name of the package.
#
# For example, the following two packages are equivalent:
# arch = [
# "metapac",
# { package = "metapac" }
# ]
arch = [
"package1",
{ package = "package2" },
{ package = "syncthing", hooks = { after_sync = [
"sudo",
"systemctl",
"enable",
"--now",
"syncthing@ripytide",
] } },
{ package = "openssh", hooks = { after_sync = [
"sudo",
"systemctl",
"enable",
"--now",
"sshd",
] } },
{ package = "fastfetch", hooks = { before_install = [
"echo",
"before_install",
], after_install = [
"echo",
"after_install",
], before_sync = [
"echo",
"before_sync",
], after_sync = [
"echo",
"after_sync",
] } },
]
apt = ["package1", { package = "package2" }]
brew = ["package1", { package = "package2" }]
bun = ["package1", { package = "package2" }]
cargo = [
"package1",
# see cargo docs for info on the options
{ package = "package2", options = { git = "https://github.com/ripytide/metapac", all_features = true, no_default_features = false, features = [
"feature1",
], locked = true } },
]
dnf = [
"package1",
# see dnf docs for more info on these options
{ package = "package2", options = { repo = "/etc/yum.repos.d/fedora_extras.repo" } },
]
flatpak = [
"package1",
{ package = "package2", options = { remote = "flathub", systemwide = false } },
]
npm = ["package1", { package = "package2" }]
pipx = ["package1", { package = "package2" }]
pnpm = ["package1", { package = "package2" }]
scoop = ["main/metapac1", { package = "main/package2" }]
snap = [
"package1",
{ package = "package2" },
# see https://snapcraft.io/docs/snap-confinement for more info on confinement
{ package = "package3", options = { confinement = "strict" } },
{ package = "package4", options = { confinement = "classic" } },
{ package = "package5", options = { confinement = "dangerous" } },
{ package = "package6", options = { confinement = "devmode" } },
{ package = "package7", options = { confinement = "jailmode" } },
]
uv = ["package1", { package = "package2" }]
vscode = ["package1", { package = "package2" }]
winget = ["ripytide.package1", { package = "ripytide.package2" }]
xbps = ["package1", { package = "package2" }]
yarn = ["package1", { package = "package2" }]Here is a list of package managers we would like to support along with any reasons why we can't yet if any. Feel free to add to this list if you know of any other package managers we should be aware of.
cgwin: no attempt made yetchoco: no attempt made yetdeno: can't list installed global packages denoland/deno#28230guix: no attempt made yetnix: no attempt made yetpip: we supportpipxinstead which only allows you to install cli programs which makes sense for a global package managerpkg: no attempt made yetports: no attempt made yetpkgsrc: no attempt made yetsdk: can't list installed packages sdkman/sdkman-cli#466. The project is being rewritten in rust with the intention to implement the command in the new version https://github.com/sdkman/sdkman-cli-native, also see ripytide#86yum: project deprecated in favor ofdnfmise: no attempt made yet
- decman: written in python, archlinux specific, supports installing dotfiles
- declaro: written in shell script,
currently provides support for
apt,dnf,pacman,paruandyaybut is extensible - pacdef: written in rust, custom
file format, unmaintained, supported
pacman,apt,dnf,flatpak,pip,cargo,rustupandxbps
This project was forked from https://github.com/steven-omaha/pacdef so credits to the author(s) of that project for all their prior work.