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.
this post was submitted on 15 Jul 2025
21 points (100.0% liked)
Programming
21571 readers
251 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
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
.sqlpkgfolder 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
sqlpkgas is and install packages in their home folder (e.g.~/.sqlpkg). Otherwise, they'll create a separate.sqlpkgfor each project (we can provide a helperinitcommand 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).
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).
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...
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
step 5: There are now 57 other ones out there lol
But none for SQLite extensions, which is what the article is about.
A lot are in the arch repos, and the rest in the AUR ¯\(ツ)/¯
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!
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).