packy

The universal package manager

packages

PACKY/CLI

PACKY/CLIENT

PACKY/SERVER

PACKY

PACKY/DB

PACKY/APKBUILD

PACKY/PKGBUILD

PACKY/TESTS

PACKY/CORE
dependencies

uiop

asdf

sb-posix

sb-bsd-sockets

sb-concurrency

std

cl-ppcre

rdb

obj

net

cli

io

cry

dat
dependents

packy/tests

bin/packy

bin/skel
files

pkg.lisp

var.lisp

proto.lisp

pkgbuild.lisp

apkbuild.lisp

db.lisp

client.lisp

server.lisp

cfg.lisp

cli.lisp

packy.lisp
tests

PACKY-OBJECTS

PACKY-DB

symbols

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. bin/packy

1.1. help

packy -h

packy v0.1.0 --- Universal Package Manager

options:
  -h/--help               print help
    :doc Print help and exit.
  -l/--level              set the log level
  -v/--version            print version

commands:
  show*                   
    -t/--target

2. 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
- EDE
- ELPA
- org-publish.el
- package.el
- Mercurial
- Crates
- Pacman
- Homebrew
- Ultralisp
resources

2.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

2.2. targets

The following package registries will be supported in v1.

2.2.1. el

Emacs Lisp packages (tarballs)

2.2.2. vc

Version Control Repo bundles (tar.zst)

2.2.3. ql

Quicklisp compatible packages

2.2.4. pip

2.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