PRAXIS(7)                  Mutineer's Guide - praxis                 PRAXIS(7)

       praxis - package manager for Mutiny's package API, theory

       This page consists of documentation and other notes on the design of
       the praxis package manager.

       Starting from the bottom-up, praxis aims to be composed of multiple
       small utilities that do one thing, so as to ease frontend development
       and more importantly, to make the surface area for issues very small.
       With this design in mind, praxis can be fast and very compact, while
       providing a lot of useful functionality for developers, metadata
       consumers, and users.

       No code evaluation is used, up until the actual building of packages.
       All code is generated purely by following hierarchies of inheritance
       for actions and metadata.

       Concepts like envdirs <https://skarnet.org/software/s6/s6-envdir.html>
       are used to additionally ease the amount of parsing that must be done
       to files in order to construct metadata for packages, repositories, and

       Furthermore, another goal is ensuring that it should be possible to get
       metadata from packages without having to call out to a shell running
       arbitrary code or duplicate metadata. This has tended to be a problem
       for other source-based package formats, such as the Arch Linux AUR,
       Exherbo’s exheres-0, and Gentoo’s EAPI. That is to say, it should be
       relatively static and not actually require a shell parser for anything
       other than running the actual actions that build a package.

       •   A POSIX-compliant shell: on Mutiny this is oksh(1)
           <https://github.com/ibara/oksh>, but it is written with intent that
           anything vaguely POSIX compliant should function properly.

       •   idioms <https://git.mutiny.red/mutiny/idioms>

           •   Used in lieu of implementing a bunch of small flow functions
               into the package API.

       •   s6-portable-utils <https://skarnet.org/software/s6-portable-utils>

           •   s6-update-symlinks is used for updating repositories while
               respecting priority.

       •   Build repository management utilities

           •   repo-list - list all repositories by if they have libraries
               and/or packages.

               •   Tests

           •   repo-update - update repositories and combine them according to

               •   Tests (currently are skipped until things settle)

           •   repo-lint - lint repositories and check their validity
               according to theory(5).

               •   Tests

       •   Build theory utilities

           •   theory-construct-action - resolve and print all action (build
               script) parts of a theory.

               •   Tests

           •   theory-construct-metadata - resolve and print all metadata
               parts of a theory.

               •   Tests

           •   Open questions:

                1. Should packages be created by concatenation of things,
                   which creates a mostly self-contained and perhaps
                   easier-debugged build script, or should they be parsed more
                   heavily by the package manager itself? This needs to be
                   decided pretty soon since it basically dictates the rest of
                   the format.

       •   Build package building utilities

           •   pkg-gen - create a self-contained package script.

               •   Tests

               •   See the first open question above to understand my
                   anxieties with this format.

           •   pkg-build - run each phase of a package script

               •   Tests

       •   Multiple repositories

           •   Intra-repository dependencies

           •   Priority levels

               •   ::primary is the most important repository.

               •   Other repositories should always be able to depend on
                   libraries in repositories that are have a higher priority.

       •   Repository synchronization

           •   Use git for synchronization by default, but allow alternative
               transport/sync methods.

           •   Paludis has sync prefixes: cave sync -s local repository, which
               are really useful for fast development of repositories and
               packages within them.

       •   Something akin to apt-get source would be pretty nice - we have all
           the metadata to do just this anyway, since all packages are built
           from source.

   Example configuration
       Here’s what I’m imagining for the configuration format. Basically,
       something akin to Paludis' configuration format, but simpler.

       Options enabled on packages.

           *           -* ruby ssl
           tz          leaps
           toybox      static
           nginx       webdav pcre

       Files may also be put in /etc/praxis/options.d/*.conf, and they’ll take
       priority over options.conf.

       Packages explicitly requested to be installed by the user. They were
       not installed as dependencies of other packages.


       Named as such to conform with the rest of the Mutiny naming scheme.
       "Praxis," the word, means in the original Greek, "action." Packages are
       referred to as theories, thus praxis carries out a theory(3). praxis is
       the reference implementation of the package manager used by mutiny(7).


       The canonical URL of this repository is
       <https://git.mutiny.red/mutiny/praxis>.  Submit patches and bugs to <

       There is also an IRC channel for praxis and other projects at
       <irc://irc.freenode.net/#mutiny>.  Please don’t hesitate to message if
       you need help.

       praxis is in the public domain.

       To the extent possible under law, Kylie McClain < <kylie@somas.is>> has
       waived all copyright and related or neighboring rights to this work.


Mutiny                            2020-07-09                         PRAXIS(7)