mirror of
https://github.com/nushell/nushell
synced 2024-12-26 04:53:09 +00:00
0c4d5330ee
# Description This breaks `nu-plugin` up into four crates: - `nu-plugin-protocol`: just the type definitions for the protocol, no I/O. If someone wanted to wire up something more bare metal, maybe for async I/O, they could use this. - `nu-plugin-core`: the shared stuff between engine/plugin. Less stable interface. - `nu-plugin-engine`: everything required for the engine to talk to plugins. Less stable interface. - `nu-plugin`: everything required for the plugin to talk to the engine, what plugin developers use. Should be the most stable interface. No changes are made to the interface exposed by `nu-plugin` - it should all still be there. Re-exports from `nu-plugin-protocol` or `nu-plugin-core` are used as required. Plugins shouldn't ever have to use those crates directly. This should be somewhat faster to compile as `nu-plugin-engine` and `nu-plugin` can compile in parallel, and the engine doesn't need `nu-plugin` and plugins don't need `nu-plugin-engine` (except for test support), so that should reduce what needs to be compiled too. The only significant change here other than splitting stuff up was to break the `source` out of `PluginCustomValue` and create a new `PluginCustomValueWithSource` type that contains that instead. One bonus of that is we get rid of the option and it's now more type-safe, but it also means that the logic for that stuff (actually running the plugin for custom value ops) can live entirely within the `nu-plugin-engine` crate. # User-Facing Changes - New crates. - Added `local-socket` feature for `nu` to try to make it possible to compile without that support if needed. # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` |
||
---|---|---|
.. | ||
tests | ||
command.rs | ||
config_files.rs | ||
ide.rs | ||
logger.rs | ||
main.rs | ||
README.md | ||
run.rs | ||
signals.rs | ||
terminal.rs | ||
test_bins.rs | ||
tests.rs |
Nushell REPL
This directory contains the main Nushell REPL (read eval print loop) as part of the CLI portion of Nushell, which creates the nu
binary itself.
Current versions of the nu
binary will use the Nu argument parsing logic to parse the commandline arguments passed to nu
, leaving the logic here to be a thin layer around what the core libraries.