Add nu-complete cache helper

[steinuil]

I wanted to propose a solution to issues with very slow command completions (as mentioned in nushell/nushell#11733 and #588) with a command that caches closure outputs in a SQLite db with an explicit expiration.

Usage

This can be used in custom completion functions to temporarily cache the output.

def "nu-complete kubectl services" [] {
  nu-complete cache --expire 1min {
     ^kubectl get services -o name | parse "service/{value}"
  }
}

Open points

• Does it make sense to use the in-memory store for this? Since this is supposed to speed up slow commands, maybe the performance hit of just querying a disk DB would be negligible in comparison, and I would expect the DB to grow a lot in size after a while.
• How and when do we clean up this DB?
• Does it make sense to use view source on the closure as a key into this cache?
• Can we check if the closure takes any arguments and throw an error?
• Should the location of this DB be configurable? For now I just dropped it into XDG_CACHE_HOME, but not every system has that env variable available.

This is very much a WIP, if you have any suggestions please mention it!

[fdncred]

This sounds cool to me. Here's my two cents.

Does it make sense to use the in-memory store for this? Since this is supposed to speed up slow commands, maybe the performance hit of just querying a disk DB would be negligible in comparison, and I would expect the DB to grow a lot in size after a while.

I think i'd start out with in-mem and later add a file db option if people ask for it.

How and when do we clean up this DB?

With in-mem it's pretty easy. When you exit nushell, it's gone. Or, you can do stor reset. Or, you can do regular sql commands to clean things up at some interval stored in the db.

Does it make sense to use view source on the closure as a key into this cache?

That's tricky. You may have to try a few things to find out what works best.

Can we check if the closure takes any arguments and throw an error?

If you try to execute it without args it may create an error. You could also maybe look at the view source output. There's not an introspection way to determine this, that I know of.

Should the location of this DB be configurable? For now, I just dropped it into XDG_CACHE_HOME, but not every system has that env variable available.

I'd make it a parameter with a default location.