Adding this collection as a project dependency would be opposite of "lean". Better to manually collect the functions you need, favoring the well maintained and tested sqlite code base over other sources.
Adding this collection as a project dependency would be opposite of "lean". Better to manually collect the functions you need, favoring the well maintained and tested sqlite code base over other sources.
sqlean's existence provides the kernel around which other things in the ecosystem can coalesce. For example, karlb's sqlite-sqlean pip module [1], which makes it easy to get these extensions in any Python project in a cross-platform manner.
I've used the math library myself recently: the SQLite in my distro is 3.31. I could install the tooling necessary to build a new SQLite, or I could use this project.
I also use the crypto library in my datasette-ui-extras library, which can run on a variety of end-user platforms. It's nice not to have think about the packaging myself.
To each their own, of course! But for me, calling this "mostly noise" is a disservice to its maintainers.
Even the main set extensions are split into modules, rather than released as a single binary - so people can use them independently.
As for 'noise'. Well, good luck implementing `regexp_substr` and `regexp_replace` using the well-maintained and tested sqlite codebase. Or streaming file I/O.
I still haven't found a good, reliable method of upgrading the SQLite version that is made available to Python's "sqlite3" standard library module for example, that works reliably across Linux and macOS. https://til.simonwillison.net/sqlite/ld-preload is one mechanism I've explored, but it's not ideal.
As such, extensions which package stuff that you could get in SQLite core if you had a good way of recompiling that with extra options are really useful.