As I'm working through one project, I'm frequently planning the next. I noticed that a number of my future ideas, fantasies as you will, all have one thing in common: packages. It doesn't if it is a game idea or working on programming calendars or Author Intrusion, they all need some form of package management.

Given that and the rule of three, it makes sense to sit back and working that problem independent of the individual projects. Some people call this procrastinations. I like to call it composition. After a few months of rolling it around in my head, plus a bit of thoughts from Drew DeVault's various posts on the topic, I figured I'd codify my ideas and see what I can do to create something I'm happy with in the future.

Series

This is going to be a series of posts, but I have no idea of how fast I'll be writing them out or if it will pan out, but this is a list of the related posts. I want to work out my ideas, maybe have a few conversations, and then start to move to more technical concepts.

• 2023-02-07 Package Management - Introduction
• 2023-02-08 Package Management - Versions
• 2023-02-12 Package Management - Identifiers
• 2023-02-13 Package Management - Dependencies
• 2023-09-20 Package Management - Identifiers 2
• 2023-11-30 Package Management - Formats and Registries

Package Systems

Packages are awesome because they allow over developers provide components, they split apart logic into smaller chunks which make it easier to understand, and they can have different update paths instead of needing a single monolithic deployment. This also means, I'm more likely to be able to focus on a small part instead of having to “swap in” an entire project. That is one thing that has made Nitride a lot more enjoyable to work with.

At their core idea, a package is just a “blob” of something along with metadata. For purposes of this series, I don't care what is in the blob. It could be C# code, a WASM binary, or Rust source. The thing I've gotten hung up is that we have a ton of different package systems (e.g., LISP modules, Python packages, NPM, Minetest, Debian packages) and each one was written for a specific use and has different rules. Some are nicer on the disk, others support signed code, and some have methods to avoid squatters. Every community wants to write their own for their specific uses, but to me it feels like we are reinventing the wheel so many times when we could be focusing on more fun things (unless packaging systems is your idea of fun, it is mine).

(Yes, I'm aware that I want to write my own for my own specific purpose, but that's going to happen anyways. It's just a matter of what framework I write it in.)

Terminology

Since I'm thinking about doing a series of posts, here are some terms I plan on using:

• Application - Whatever needs a package, be it a game, library, or utility.
• Bakfu - My hypothetical system for managing packages. This is the Lojban word for “package” and seems like a decent handle for what I'm working for.
• Foreign - Another packaging system.
• Package Ecosystem - All the servers, tools, and the packages themselves for a given type of packaging. This includes bakfu and foreign packaging ecosystems.
• Package Server - The servers used to query and distribute packages.
• Package - A specific type of package. This will have bakfu, application, or foreign as an adjective when necessary.
• Package Content - The “thing” being packaged. This can be a set of files, a word list, assets for a game, or even a foreign package. For purposes of these posts, this is a generic “blob” of data that is specific to an application.

Bakfu

I want something generic. More specifically, I want to find what I consider are the “best” parts of the various systems I've worked with, solve problems that I've experienced, and maybe come up with a set of libraries and utilities that let me implement a packaging ecosystem that only requires me to override the application-specific components while delegating the rest of the ecosystem to bakfu.

I have no intent on this being a “standard” because everyone likes to reinvent the wheel. Everyone has their own idea of what is the “right” way of handling packages, even when there is a defacto standard already implemented.

That isn't to say this is only going to be for me. Like most of my work, I'm hoping to create something generic enough that others can use it for any purpose and in the languages of their choice and still get some of the benefits I envision.