Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

key-value module for std-rfc #965

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

NotTheDr01ds
Copy link
Contributor

Simple getters and setters for key-value pairs in a pipeline.

From the help:

kv module

use std-rfc/kv *

Easily store and retrieve key-value pairs
in a pipeline.

A common request is to be able to assign a
pipeline result to a variable. While it's
not currently possible to use a "let" statement
within a pipeline, this module provides an
alternative. Think of each key as a variable
that can be set and retrieved.

kv set

Stores the pipeline value for later use

Usage:

<input> | kv set <key> <value?>

Examples:

ls ~ | kv set "home snapshot"
kv set foo 5

kv get

Retrieves a stored value by key

Counterpart of kv set.

Returns null if the key is not found.

Usage:

kv get <key> | <pipeline>

kv list

List the currently stored key-value pairs

Returns results as the Nushell value rather
than the stored nuon.

kv drop

Returns and removes a key-value pair

@NotTheDr01ds
Copy link
Contributor Author

NotTheDr01ds commented Oct 2, 2024

Before anyone asks, I wrote this as a set of space-separated-commands, rather than a <module> subcommand because get is a built in. Attempting to define:

export def get ...

... was clobbering/shadowing the internal get. It's possible workaround this in one of two ways:

  1. Avoid get, which is possible, since it is mostly syntactic sugar for | $in.<cell-path>
  2. Make the name kv get to avoid shadowing.

Option 1 resulted in some "less readable" code and was also more "dangerous", since if someone imported the module with use std-rfc/kv * instead of use std-rfc/kv, it would shadow the built-in and clobber most any other module in memory.

So I went with Option 2 ;-)

@fdncred
Copy link
Collaborator

fdncred commented Oct 2, 2024

I have no real problem with this but I wonder what our process should be for adding something to the stdlib. Seems like it should be more formal with voting or something. Not sure.

@NotTheDr01ds
Copy link
Contributor Author

Agreed - I was thinking the same thing while i was working on these. It's something we have to figure out if we hope to open up std once again.

Possibilities:

  • Telemetry ... Kidding. Mostly. Could be opt-in with an environment variable where it just pings (http get) some URL to update a counter. Longer-term, pie-in-the-sky.

  • Probably something more realistic like an "issue" thread here for commenting and upvotes. One thread per command (or potentially module). Reaches some level of upvotes (currently pretty low) and it gets moved forward?

  • Special-case core-team votes. I seem to recall you saying that right now it takes two core team to move a PR forward (or something like that; not sure if there's anything official).

@NotTheDr01ds NotTheDr01ds marked this pull request as draft October 3, 2024 15:23
@NotTheDr01ds
Copy link
Contributor Author

I'll add tests for this one as well before bringing out of draft.

Any thoughts on whether I should use msgpackz in place of nuon for the value pickling?

@fdncred
Copy link
Collaborator

fdncred commented Oct 3, 2024

You'd have to do some tests to see if it makes any difference because with msgpackz you have to pay for creating msgpack and brotli for compression/decompression.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants