Writing a package manager

Writing a package manager (antonz.org)
from cm0002@lemmy.world to programming@programming.dev on 15 Jul 2025 14:12
https://lemmy.world/post/33004747

#programming

threaded - newest

zombiewarrior@techhub.social on 15 Jul 2025 14:14 next collapse

@cm0002

step 1: ask yourself, why am i writing a package manager where there are like 56 other ones out there

step 2: ok but really, is that a good enough reason

step 3: really?

step 4: no, it's not, stop

cm0002@lemmy.world on 15 Jul 2025 14:48 next collapse

step 5: There are now 57 other ones out there lol

Deebster@infosec.pub on 15 Jul 2025 15:58 collapse

But none for SQLite extensions, which is what the article is about.

30p87@feddit.org on 15 Jul 2025 16:47 collapse

A lot are in the arch repos, and the rest in the AUR ¯\(ツ)/¯

atzanteol@sh.itjust.works on 15 Jul 2025 14:53 next collapse

UndercoverUlrikHD@programming.dev on 15 Jul 2025 15:09 collapse

First paragraphs in the article

Writing a package manager is not one of the most common programming tasks. After all, there are many out-of-the-box ones available. Yet, somehow I’ve found myself in exactly this situation.

How so?

I’m a big fan of SQLite and its extensions. Given the large number of such extensions in the wild, I wanted a structured approach to managing them. Which usually involves, well, a package manager. Except there is none for SQLite. So I decided to build one!

atzanteol@sh.itjust.works on 15 Jul 2025 20:47 collapse

Having a reason is not the same as having a good reason.

Hence my facetious “but why?” (I had read the article - they don’t justify it well).

shape_warrior_t@programming.dev on 15 Jul 2025 15:49 next collapse

Interesting way of handling project vs global scope:

Some package managers (e.g. npm) use per-project scope by default, but also allow you to install packages globally using flags (npm install -g). Others (e.g. brew) use global scope.

I like the idea of allowing both project and global scope, but I do not like the flags approach. Why don’t we apply a heuristic:

If there is a .sqlpkg folder in the current directory, use project scope. Otherwise, use global scope.

This way, if users don’t need separate project environments, they will just run sqlpkg as is and install packages in their home folder (e.g. ~/.sqlpkg). Otherwise, they’ll create a separate .sqlpkg for each project (we can provide a helper init command for this).

Seems rather implicit, though, especially if the command output doesn’t specify which scope a package was installed in. If a user moves to a subdirectory, forgets they are there, and then tries to install a package, the package will unexpectedly install in global scope (though this particular version of the problem can be solved by also looking in parent directories).

nous@programming.dev on 15 Jul 2025 16:04 next collapse

Yeah I don’t like this either. So many chances for a mistake, be in the wrong dir, file misspelled, something not cloned correctly or anything else not setup as you think it might be and suddenly the package manage does something you don’t expect (like try to install globally rather then in a project or vice versa).

devfuuu@lemmy.world on 15 Jul 2025 16:15 collapse

It’s absolutely horrible indeed. Confusing with where you are, accidentally thinking you doing one thing and doing another, versions conflicts or other things happening without understanding…

eager_eagle@lemmy.world on 15 Jul 2025 19:35 collapse

This way, if users don’t need separate project environments, they will just run sqlpkg as is and install packages in their home folder (e.g. ~/.sqlpkg)

XDG dirs or nothing. Don’t touch my home directory.