Re: Unboxed package manager

[Jonas Bernoulli <jonas@bernoul.li>]

Lynn Winebarger <owinebar@gmail.com> writes:

> I think I'm going to hack something together starting with advice on the
> existing package management and taking some inspiration from the design of
> Jonas Bernoulli's epkg and emir packages for tracking installed packages
> and component files in a SQLite database.

If I were to start over now, I wouldn't write Closql.  At the time it
made a lot of sense because I knew nothing about databases and because
it allowed me to switch out the old data store ("everything is *its own*
file") without changing internal interfaces much.  Moving from files to
a database did wonders for performance, so at first I didn't mind the
performance impact of the OO interface on top of the database.
Meanwhile I have moved away from the OO interface for anything that
deals with more than one package at a time, turning many rows into
EIEIO objects is a bit costly.

When I switched to SQLite, Emacs had no built-in support (coming in
Emacs 29) and there also was no module, so EmacSQL was the natural
choice.  I am the maintainer of that now, so I definitely think it
serves a purpose, but I do have some reservations.

The next release will feature new backends that use the built-in support
and a module, but if I were to start now, I probably would go with the
built-in support directly.

EmacSQL allows writing SQL using vectors instead of concatenating
strings, which is nice, but for people just getting started with SQL, it
has the disadvantage that you now have to learn two things, SQL and the
almost SQL vector syntax, which isn't 100% complete and doesn't map 1:1.

The main limitation of EmacSQL is that it stores everything (except
NULL) as a string.  This is why I would probably avoid it now, because
it limits interoperability with anything that doesn't use EmacSQL.