From my limited exploring this is mostly noise. For example, math lib is taken from recent sqlite and backported, useful only if your sqlite lib is more than 2 years old. Quite a few extensions are taken from 'ext' dir in sqlite sources. Others are redundant and trivial; why use a specialized cube-root extension when you can directly calculate pow(_, 1/3)?
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.
I use sqlean for the same reason that I use any pre-built library: it makes my life easier.
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.
I don't expect anyone to use all the incubator extensions (like the cube root you mentioned). They are in the incubator and not in the main set for a reason.
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.
It can be surprising difficult to upgrade to a more recent SQLite release, depending on your operating system and which language bindings you are using.
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.
They take a very conservative approach towards reliability and won't enable features unless they feel it's rock solid. It's a small team and a big change.
That said, the rate of refinements and new features is quite impressive.
, where it says: "Note that SQLite will process an SQL SELECT statement tree against an FTS table in three phases: ... The final phase rewrite the query from the inner join into an outer join.", and
I'm the author of the extension that the vtab and define function in that module were adapted from. It allows you to create something like a parameterized view, but the way it works is fairly simple: a prepared statement is created from the provided SQL on the same db connection as the vtab, and is executed each time the virtual table is queried. Parameters can be supplied as constraints (or using table valued function syntax) and the results of executing the statement are the row values.
One of the issues I've had is using custom extensions on aws lambda with python. Even if you build them properly it really doesn't like to load extra native code.
You can compile this in too, but from a quick review none of my various SQLite installations seem to have been compiled with the SQLITE_ENABLE_ICU flag.
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.