nushell/crates/nu_plugin_python/nu_plugin_python_example.py

268 lines
8.2 KiB
Python
Raw Normal View History

#!/usr/bin/env python
# Example of using a Python script as a Nushell plugin
#
# The example uses JSON encoding but it should be a similar process using
# msgpack to move data between Nushell and the plugin. The only difference
# would be that you need to use msgpack relative lib(like msgpack) to
# decode and encode information that is read and written to stdin and stdout
#
# To register the plugin use:
# plugin add <path-to-py-file>
#
# Be careful with the spans. Miette will crash if a span is outside the
# size of the contents vector. We strongly suggest using the span found in the
# plugin call head as in this example.
#
# The plugin will be run using the active Python implementation. If you are in
# a Python environment, that is the Python version that is used
#
# Note: To keep the plugin simple and without dependencies, the dictionaries that
# represent the data transferred between Nushell and the plugin are kept as
# native Python dictionaries. The encoding and decoding process could be improved
# by using libraries like pydantic and marshmallow
#
# This plugin uses python3
# Note: To debug plugins write to stderr using sys.stderr.write
import sys
import json
2024-10-20 23:12:41 +02:00
NUSHELL_VERSION = "0.99.2"
PLUGIN_VERSION = "0.1.1" # bump if you change commands!
def signatures():
"""
Multiple signatures can be sent to Nushell. Each signature will be registered
as a different plugin function in Nushell.
In your plugin logic you can use the name of the signature to indicate what
operation should be done with the plugin
"""
return {
"Signature": [
{
"sig": {
"name": "nu-python",
"description": "Signature test for Python",
"extra_description": "",
"required_positional": [
{
"name": "a",
"desc": "required integer value",
"shape": "Int",
},
{
"name": "b",
"desc": "required string value",
"shape": "String",
},
],
"optional_positional": [
{
"name": "opt",
"desc": "Optional number",
"shape": "Int",
}
],
"rest_positional": {
"name": "rest",
"desc": "rest value string",
"shape": "String",
},
"named": [
{
"long": "help",
"short": "h",
"arg": None,
"required": False,
"desc": "Display the help message for this command",
},
{
"long": "flag",
"short": "f",
"arg": None,
"required": False,
"desc": "a flag for the signature",
},
{
"long": "named",
"short": "n",
"arg": "String",
"required": False,
"desc": "named string",
},
],
"input_output_types": [["Any", "Any"]],
"allow_variants_without_examples": True,
"search_terms": ["Python", "Example"],
"is_filter": False,
"creates_scope": False,
"allows_unknown_args": False,
"category": "Experimental",
},
"examples": [],
}
]
}
def process_call(id, plugin_call):
"""
plugin_call is a dictionary with the information from the call
It should contain:
- The name of the call
- The call data which includes the positional and named values
- The input from the pipeline
Use this information to implement your plugin logic
"""
# Pretty printing the call to stderr
2021-12-19 11:00:31 +01:00
sys.stderr.write(json.dumps(plugin_call, indent=4))
sys.stderr.write("\n")
# Get the span from the call
span = plugin_call["call"]["head"]
# Creates a Value of type List that will be encoded and sent to Nushell
def f(x, y):
return {"Int": {"val": x * y, "span": span}}
Local socket mode and foreground terminal control for plugins (#12448) # Description Adds support for running plugins using local socket communication instead of stdio. This will be an optional thing that not all plugins have to support. This frees up stdio for use to make plugins that use stdio to create terminal UIs, cc @amtoine, @fdncred. This uses the [`interprocess`](https://crates.io/crates/interprocess) crate (298 stars, MIT license, actively maintained), which seems to be the best option for cross-platform local socket support in Rust. On Windows, a local socket name is provided. On Unixes, it's a path. The socket name is kept to a relatively small size because some operating systems have pretty strict limits on the whole path (~100 chars), so on macOS for example we prefer `/tmp/nu.{pid}.{hash64}.sock` where the hash includes the plugin filename and timestamp to be unique enough. This also adds an API for moving plugins in and out of the foreground group, which is relevant for Unixes where direct terminal control depends on that. TODO: - [x] Generate local socket path according to OS conventions - [x] Add support for passing `--local-socket` to the plugin executable instead of `--stdio`, and communicating over that instead - [x] Test plugins that were broken, including [amtoine/nu_plugin_explore](https://github.com/amtoine/nu_plugin_explore) - [x] Automatically upgrade to using local sockets when supported, falling back if it doesn't work, transparently to the user without any visible error messages - Added protocol feature: `LocalSocket` - [x] Reset preferred mode to `None` on `register` - [x] Allow plugins to detect whether they're running on a local socket and can use stdio freely, so that TUI plugins can just produce an error message otherwise - Implemented via `EngineInterface::is_using_stdio()` - [x] Clean up foreground state when plugin command exits on the engine side too, not just whole plugin - [x] Make sure tests for failure cases work as intended - `nu_plugin_stress_internals` added # User-Facing Changes - TUI plugins work - Non-Rust plugins could optionally choose to use this - This might behave differently, so will need to test it carefully across different operating systems # Tests + Formatting - :green_circle: `toolkit fmt` - :green_circle: `toolkit clippy` - :green_circle: `toolkit test` - :green_circle: `toolkit test stdlib` # After Submitting - [ ] Document local socket option in plugin contrib docs - [ ] Document how to do a terminal UI plugin in plugin contrib docs - [ ] Document: `EnterForeground` engine call - [ ] Document: `LeaveForeground` engine call - [ ] Document: `LocalSocket` protocol feature
2024-04-15 20:28:18 +02:00
value = {
"Value": [
{
"List": {
"vals": [
{
"Record": {
"val": {
"one": f(x, 0),
"two": f(x, 1),
"three": f(x, 2),
},
"span": span,
}
}
for x in range(0, 10)
],
"span": span,
}
},
None,
]
}
write_response(id, {"PipelineData": value})
def tell_nushell_encoding():
sys.stdout.write(chr(4))
for ch in "json":
sys.stdout.write(chr(ord(ch)))
sys.stdout.flush()
def tell_nushell_hello():
"""
A `Hello` message is required at startup to inform nushell of the protocol capabilities and
compatibility of the plugin. The version specified should be the version of nushell that this
plugin was tested and developed against.
"""
hello = {
"Hello": {
2024-06-05 00:52:40 +02:00
"protocol": "nu-plugin", # always this value
"version": NUSHELL_VERSION,
"features": [],
}
}
sys.stdout.write(json.dumps(hello))
sys.stdout.write("\n")
sys.stdout.flush()
def write_response(id, response):
"""
Use this format to send a response to a plugin call. The ID of the plugin call is required.
"""
wrapped_response = {
"CallResponse": [
id,
response,
]
}
sys.stdout.write(json.dumps(wrapped_response))
sys.stdout.write("\n")
sys.stdout.flush()
def write_error(id, text, span=None):
"""
Use this error format to send errors to nushell in response to a plugin call. The ID of the
plugin call is required.
"""
error = (
{
"Error": {
"msg": "ERROR from plugin",
"labels": [
{
"text": text,
"span": span,
}
],
}
}
if span is not None
else {
"Error": {
"msg": "ERROR from plugin",
"help": text,
}
}
)
write_response(id, error)
def handle_input(input):
if "Hello" in input:
if input["Hello"]["version"] != NUSHELL_VERSION:
exit(1)
else:
return
elif input == "Goodbye":
exit(0)
elif "Call" in input:
[id, plugin_call] = input["Call"]
Allow plugins to report their own version and store it in the registry (#12883) # Description This allows plugins to report their version (and potentially other metadata in the future). The version is shown in `plugin list` and in `version`. The metadata is stored in the registry file, and reflects whatever was retrieved on `plugin add`, not necessarily the running binary. This can help you to diagnose if there's some kind of mismatch with what you expect. We could potentially use this functionality to show a warning or error if a plugin being run does not have the same version as what was in the cache file, suggesting `plugin add` be run again, but I haven't done that at this point. It is optional, and it requires the plugin author to make some code changes if they want to provide it, since I can't automatically determine the version of the calling crate or anything tricky like that to do it. Example: ``` > plugin list | select name version is_running pid ╭───┬────────────────┬─────────┬────────────┬─────╮ │ # │ name │ version │ is_running │ pid │ ├───┼────────────────┼─────────┼────────────┼─────┤ │ 0 │ example │ 0.93.1 │ false │ │ │ 1 │ gstat │ 0.93.1 │ false │ │ │ 2 │ inc │ 0.93.1 │ false │ │ │ 3 │ python_example │ 0.1.0 │ false │ │ ╰───┴────────────────┴─────────┴────────────┴─────╯ ``` cc @maxim-uvarov (he asked for it) # User-Facing Changes - `plugin list` gets a `version` column - `version` shows plugin versions when available - plugin authors *should* add `fn metadata()` to their `impl Plugin`, but don't have to # Tests + Formatting Tested the low level stuff and also the `plugin list` column. # After Submitting - [ ] update plugin guide docs - [ ] update plugin protocol docs (`Metadata` call & response) - [ ] update plugin template (`fn metadata()` should be easy) - [ ] release notes
2024-06-21 13:27:09 +02:00
if plugin_call == "Metadata":
write_response(
id,
{
"Metadata": {
"version": PLUGIN_VERSION,
}
},
)
Allow plugins to report their own version and store it in the registry (#12883) # Description This allows plugins to report their version (and potentially other metadata in the future). The version is shown in `plugin list` and in `version`. The metadata is stored in the registry file, and reflects whatever was retrieved on `plugin add`, not necessarily the running binary. This can help you to diagnose if there's some kind of mismatch with what you expect. We could potentially use this functionality to show a warning or error if a plugin being run does not have the same version as what was in the cache file, suggesting `plugin add` be run again, but I haven't done that at this point. It is optional, and it requires the plugin author to make some code changes if they want to provide it, since I can't automatically determine the version of the calling crate or anything tricky like that to do it. Example: ``` > plugin list | select name version is_running pid ╭───┬────────────────┬─────────┬────────────┬─────╮ │ # │ name │ version │ is_running │ pid │ ├───┼────────────────┼─────────┼────────────┼─────┤ │ 0 │ example │ 0.93.1 │ false │ │ │ 1 │ gstat │ 0.93.1 │ false │ │ │ 2 │ inc │ 0.93.1 │ false │ │ │ 3 │ python_example │ 0.1.0 │ false │ │ ╰───┴────────────────┴─────────┴────────────┴─────╯ ``` cc @maxim-uvarov (he asked for it) # User-Facing Changes - `plugin list` gets a `version` column - `version` shows plugin versions when available - plugin authors *should* add `fn metadata()` to their `impl Plugin`, but don't have to # Tests + Formatting Tested the low level stuff and also the `plugin list` column. # After Submitting - [ ] update plugin guide docs - [ ] update plugin protocol docs (`Metadata` call & response) - [ ] update plugin template (`fn metadata()` should be easy) - [ ] release notes
2024-06-21 13:27:09 +02:00
elif plugin_call == "Signature":
write_response(id, signatures())
elif "Run" in plugin_call:
process_call(id, plugin_call["Run"])
else:
write_error(id, "Operation not supported: " + str(plugin_call))
else:
sys.stderr.write("Unknown message: " + str(input) + "\n")
exit(1)
def plugin():
tell_nushell_encoding()
tell_nushell_hello()
for line in sys.stdin:
input = json.loads(line)
handle_input(input)
2024-06-05 00:52:40 +02:00
if __name__ == "__main__":
if len(sys.argv) == 2 and sys.argv[1] == "--stdio":
plugin()
else:
Bump to version 0.99.0 (#14094) <!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) and talk to the core team before making major changes. Description of your pull request goes here. **Provide examples and/or screenshots** if your changes affect the user experience. --> # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
2024-10-15 21:01:08 +02:00
print("Run me from inside nushell!")