packy

The universal package manager

PACKY/CLI
PACKY/CLIENT
PACKY/SERVER
PACKY
PACKY/DB
PACKY/APKBUILD
PACKY/PKGBUILD
PACKY/TESTS
PACKY/CORE
uiop
asdf
sb-posix
sb-bsd-sockets
sb-concurrency
std
cl-ppcre
rdb
obj
net
cli
io
cry
dat
packy/tests
core/lib
bin/packy
bin/skel
pkg.lisp
var.lisp
proto.lisp
pkgbuild.lisp
apkbuild.lisp
db.lisp
client.lisp
server.lisp
cfg.lisp
cli.lisp
packy.lisp
PACKY-OBJECTS
PACKY-DB
*PACKY-URL*
PACKY-ERROR
PACKAGE-DEPENDENCY
PACKAGE-VERSION
PACKY-SERVICE
*PACKY-DB*
SYNC-PACKAGE
*PACKY-HOME*
PULL-PACKAGE
BUILD-PACKAGE
PREPARE-PACKAGE
UPDATE-PACKAGE
PACKY-CONDITION
PACKY-SERVER
UNPACK
LIST-PACKAGES
*DEFAULT-PACKY-DIST-TARGETS*
*PACKY-DIST-TARGETS*
UNINSTALL-PACKAGE
*PACKY-CLI*
PACKY-USER-CONFIG
*PACKY-LOGGER*
PK-INDEX
PACKY-CONFIG
INIT-PACKY
*PACK*
CHECK-PACKAGE
PACKAGE-SOURCE
*PACKY-COMPRESSOR*
PACKAGE-REGISTRY
PACKY-CLIENT
*PACKY-DECOMPRESSOR*
*PACKY-REGISTRY*
QUERY-PACKAGE
PACK
INSTALL-PACKAGE
BUNDLE-PACKAGE
PUSH-PACKAGE

1. Notes

  • why
    • we have standards for everything nowadays.. container images (OCI), language servers (LSP), Emoji codes.. why not packages and package managers?
    • what happens if upstream package registries go down during release CI? (ur fukt)
    • decent amount of external traffic comes from package registry streams (CITE)
      • ezpz - cache it locally, and reduce cost at the same time
    • data proximity matters
    • public registries are ripe for supply-chain attacks
    • there are too many package managers, and it's unreasonable to demand our clients rely on them
      • needless external footprint - keep this traffic away from bad actors and inside the corporate VPN
    • traffic control matters
  • how
    • sexps
      • define spec in CLOS (lisp objects)
      • define validation tools
      • use tools to validate implementations
    • compilers
      • functionality composed of lambdas and closures
        • insert hooks, custom settings, flags
      • ability to define optimization passes
      • dependency traversal, cycle detection
      • macros
  • goals
    • simple design
    • extensibility
    • introspectable (from client and server)
  • inspiration
  • resources

1.1. Design

  • core classes
    • package
    • source
    • collection
    • op
    • env
  • mixed
    • registry source + collection
    • dependency source + package
    • client
      • op+env
    • server
      • op+collection+env
    • peer
      • client+server

1.2. targets

The following package registries will be supported in v1.

1.2.1. el

Emacs Lisp packages (tarballs)

1.2.2. vc

Version Control Repo bundles (tar.zst)

  1. hg
  2. git

1.2.3. ql

Quicklisp compatible packages

1.2.4. pip

1.2.5. crater

This is a private crate registry for the Rust programming language.

The crates.io package registry provides a number of excellent crates, integrates well with the cargo development tool, and should be preferred in all cases. I use crater when I need to:

  • import my unpublished crates
  • import the master branch of a published crate
  • import a local or patched version of a published crate
  • import a non-git crate (hg)

crater also works well in intranet/local environments, and can be deployed for use in the following ways:

remote
same as crates.io, registry index is publicly hosted on GitHub (default)
local
registry index is stored locally, crates are retrieved remotely
static
registry index and crate sources are stored locally, no network requests are required