nushell/Cargo.toml

204 lines
6.2 KiB
TOML
Raw Normal View History

2019-05-10 18:59:12 +02:00
[package]
2019-05-17 01:39:58 +02:00
name = "nu"
version = "0.6.2"
2019-08-23 07:36:52 +02:00
authors = ["Yehuda Katz <wycats@gmail.com>", "Jonathan Turner <jonathan.d.turner@gmail.com>", "Andrés N. Robalino <andres@androbtech.com>"]
2019-05-16 23:46:24 +02:00
description = "A shell for the GitHub era"
2019-06-02 18:50:41 +02:00
license = "MIT"
2019-05-10 18:59:12 +02:00
edition = "2018"
2019-07-16 21:17:46 +02:00
readme = "README.md"
2019-06-27 06:56:48 +02:00
default-run = "nu"
2019-07-16 21:17:46 +02:00
repository = "https://github.com/nushell/nushell"
homepage = "https://www.nushell.sh"
2019-08-23 07:28:30 +02:00
documentation = "https://book.nushell.sh"
2019-05-10 18:59:12 +02:00
[workspace]
2019-12-04 18:51:20 +01:00
members = [
Add Range and start Signature support This commit contains two improvements: - Support for a Range syntax (and a corresponding Range value) - Work towards a signature syntax Implementing the Range syntax resulted in cleaning up how operators in the core syntax works. There are now two kinds of infix operators - tight operators (`.` and `..`) - loose operators Tight operators may not be interspersed (`$it.left..$it.right` is a syntax error). Loose operators require whitespace on both sides of the operator, and can be arbitrarily interspersed. Precedence is left to right in the core syntax. Note that delimited syntax (like `( ... )` or `[ ... ]`) is a single token node in the core syntax. A single token node can be parsed from beginning to end in a context-free manner. The rule for `.` is `<token node>.<member>`. The rule for `..` is `<token node>..<token node>`. Loose operators all have the same syntactic rule: `<token node><space><loose op><space><token node>`. The second aspect of this pull request is the beginning of support for a signature syntax. Before implementing signatures, a necessary prerequisite is for the core syntax to support multi-line programs. That work establishes a few things: - `;` and newlines are handled in the core grammar, and both count as "separators" - line comments begin with `#` and continue until the end of the line In this commit, multi-token productions in the core grammar can use separators interchangably with spaces. However, I think we will ultimately want a different rule preventing separators from occurring before an infix operator, so that the end of a line is always unambiguous. This would avoid gratuitous differences between modules and repl usage. We already effectively have this rule, because otherwise `x<newline> | y` would be a single pipeline, but of course that wouldn't work.
2019-12-04 22:14:52 +01:00
"crates/nu-macros",
2019-12-04 18:51:20 +01:00
"crates/nu-errors",
"crates/nu-source",
"crates/nu_plugin_average",
2019-12-04 18:51:20 +01:00
"crates/nu_plugin_binaryview",
2019-12-07 04:46:05 +01:00
"crates/nu_plugin_fetch",
"crates/nu_plugin_inc",
"crates/nu_plugin_match",
"crates/nu_plugin_post",
"crates/nu_plugin_ps",
"crates/nu_plugin_str",
"crates/nu_plugin_sum",
"crates/nu_plugin_sys",
"crates/nu_plugin_textview",
"crates/nu_plugin_tree",
2019-12-04 18:51:20 +01:00
"crates/nu-protocol",
"crates/nu-parser",
"crates/nu-value-ext",
2019-12-04 18:51:20 +01:00
"crates/nu-build"
]
2019-05-10 18:59:12 +02:00
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
2019-11-27 03:55:02 +01:00
nu-source = { version = "0.1.0", path = "./crates/nu-source" }
nu-protocol = { version = "0.1.0", path = "./crates/nu-protocol" }
nu-errors = { version = "0.1.0", path = "./crates/nu-errors" }
nu-parser = { version = "0.1.0", path = "./crates/nu-parser" }
nu-value-ext = { version = "0.1.0", path = "./crates/nu-value-ext" }
nu_plugin_average = {version = "0.1.0", path = "./crates/nu_plugin_average", optional=true}
2019-12-04 18:51:20 +01:00
nu_plugin_binaryview = {version = "0.1.0", path = "./crates/nu_plugin_binaryview", optional=true}
2019-12-07 04:46:05 +01:00
nu_plugin_fetch = {version = "0.1.0", path = "./crates/nu_plugin_fetch", optional=true}
nu_plugin_inc = {version = "0.1.0", path = "./crates/nu_plugin_inc", optional=true}
nu_plugin_match = {version = "0.1.0", path = "./crates/nu_plugin_match", optional=true}
2019-12-07 04:46:05 +01:00
nu_plugin_post = {version = "0.1.0", path = "./crates/nu_plugin_post", optional=true}
nu_plugin_ps = {version = "0.1.0", path = "./crates/nu_plugin_ps", optional=true}
nu_plugin_str = {version = "0.1.0", path = "./crates/nu_plugin_str", optional=true}
nu_plugin_sum = {version = "0.1.0", path = "./crates/nu_plugin_sum", optional=true}
nu_plugin_sys = {version = "0.1.0", path = "./crates/nu_plugin_sys", optional=true}
nu_plugin_textview = {version = "0.1.0", path = "./crates/nu_plugin_textview", optional=true}
nu_plugin_tree = {version = "0.1.0", path = "./crates/nu_plugin_tree", optional=true}
Add Range and start Signature support This commit contains two improvements: - Support for a Range syntax (and a corresponding Range value) - Work towards a signature syntax Implementing the Range syntax resulted in cleaning up how operators in the core syntax works. There are now two kinds of infix operators - tight operators (`.` and `..`) - loose operators Tight operators may not be interspersed (`$it.left..$it.right` is a syntax error). Loose operators require whitespace on both sides of the operator, and can be arbitrarily interspersed. Precedence is left to right in the core syntax. Note that delimited syntax (like `( ... )` or `[ ... ]`) is a single token node in the core syntax. A single token node can be parsed from beginning to end in a context-free manner. The rule for `.` is `<token node>.<member>`. The rule for `..` is `<token node>..<token node>`. Loose operators all have the same syntactic rule: `<token node><space><loose op><space><token node>`. The second aspect of this pull request is the beginning of support for a signature syntax. Before implementing signatures, a necessary prerequisite is for the core syntax to support multi-line programs. That work establishes a few things: - `;` and newlines are handled in the core grammar, and both count as "separators" - line comments begin with `#` and continue until the end of the line In this commit, multi-token productions in the core grammar can use separators interchangably with spaces. However, I think we will ultimately want a different rule preventing separators from occurring before an infix operator, so that the end of a line is always unambiguous. This would avoid gratuitous differences between modules and repl usage. We already effectively have this rule, because otherwise `x<newline> | y` would be a single pipeline, but of course that wouldn't work.
2019-12-04 22:14:52 +01:00
nu-macros = { version = "0.1.0", path = "./crates/nu-macros" }
query_interface = "0.3.5"
typetag = "0.1.4"
2019-10-30 21:14:47 +01:00
rustyline = "5.0.4"
2019-12-08 18:56:21 +01:00
chrono = { version = "0.4.10", features = ["serde"] }
2019-08-31 23:19:59 +02:00
derive-new = "0.5.8"
2019-05-10 18:59:12 +02:00
prettytable-rs = "0.8.0"
2019-12-08 18:56:21 +01:00
itertools = "0.8.2"
2019-09-13 05:44:21 +02:00
ansi_term = "0.12.1"
2019-11-10 18:48:49 +01:00
nom = "5.0.1"
2019-05-11 09:00:33 +02:00
dunce = "1.0.0"
2019-11-10 18:48:49 +01:00
indexmap = { version = "1.3.0", features = ["serde-1"] }
chrono-humanize = "0.0.11"
2019-11-10 18:48:49 +01:00
byte-unit = "3.0.3"
base64 = "0.11"
futures-preview = { version = "=0.3.0-alpha.19", features = ["compat", "io-compat"] }
async-stream = "0.1.2"
2019-08-02 21:15:07 +02:00
futures_codec = "0.2.5"
2019-12-08 18:56:21 +01:00
num-traits = "0.2.10"
term = "0.5.2"
2019-05-25 21:07:52 +02:00
bytes = "0.4.12"
2019-08-07 19:49:11 +02:00
log = "0.4.8"
2019-08-23 05:29:08 +02:00
pretty_env_logger = "0.3.1"
2019-12-08 18:56:21 +01:00
serde = { version = "1.0.103", features = ["derive"] }
2019-08-31 16:22:45 +02:00
bson = { version = "0.14.0", features = ["decimal128"] }
2019-12-08 18:56:21 +01:00
serde_json = "1.0.44"
2019-08-23 05:29:08 +02:00
serde-hjson = "0.9.1"
2019-06-03 09:41:28 +02:00
serde_yaml = "0.8"
2019-12-08 18:56:21 +01:00
serde_bytes = "0.11.3"
2019-11-10 18:48:49 +01:00
getset = "0.0.9"
2019-10-15 21:54:46 +02:00
language-reporting = "0.4.0"
app_dirs = "1.2.1"
csv = "1.1"
2019-11-10 18:48:49 +01:00
toml = "0.5.5"
clap = "2.33.0"
2019-12-08 18:56:21 +01:00
git2 = { version = "0.10.2", default_features = false }
2019-07-29 09:46:24 +02:00
dirs = "2.0.2"
glob = "0.3.0"
2019-06-07 02:31:22 +02:00
ctrlc = "3.1.3"
2019-12-08 18:56:21 +01:00
roxmltree = "0.7.3"
nom_locate = "1.0.0"
2019-11-10 18:48:49 +01:00
nom-tracable = "0.4.1"
2019-07-29 09:46:24 +02:00
unicode-xid = "0.2.0"
2019-06-16 08:43:40 +02:00
serde_ini = "0.2.0"
2019-06-18 04:04:34 +02:00
subprocess = "0.1.18"
2019-11-10 18:48:49 +01:00
pretty-hex = "0.1.1"
hex = "0.4"
tempfile = "3.1.0"
2019-11-10 18:48:49 +01:00
which = "3.1"
2019-08-16 07:47:47 +02:00
textwrap = {version = "0.11.0", features = ["term_size"]}
Add support for ~ expansion This ended up being a bit of a yak shave. The basic idea in this commit is to expand `~` in paths, but only in paths. The way this is accomplished is by doing the expansion inside of the code that parses literal syntax for `SyntaxType::Path`. As a quick refresher: every command is entitled to expand its arguments in a custom way. While this could in theory be used for general-purpose macros, today the expansion facility is limited to syntactic hints. For example, the syntax `where cpu > 0` expands under the hood to `where { $it.cpu > 0 }`. This happens because the first argument to `where` is defined as a `SyntaxType::Block`, and the parser coerces binary expressions whose left-hand-side looks like a member into a block when the command is expecting one. This is mildly more magical than what most programming languages would do, but we believe that it makes sense to allow commands to fine-tune the syntax because of the domain nushell is in (command-line shells). The syntactic expansions supported by this facility are relatively limited. For example, we don't allow `$it` to become a bare word, simply because the command asks for a string in the relevant position. That would quickly become more confusing than it's worth. This PR adds a new `SyntaxType` rule: `SyntaxType::Path`. When a command declares a parameter as a `SyntaxType::Path`, string literals and bare words passed as an argument to that parameter are processed using the path expansion rules. Right now, that only means that `~` is expanded into the home directory, but additional rules are possible in the future. By restricting this expansion to a syntactic expansion when passed as an argument to a command expecting a path, we avoid making `~` a generally reserved character. This will also allow us to give good tab completion for paths with `~` characters in them when a command is expecting a path. In order to accomplish the above, this commit changes the parsing functions to take a `Context` instead of just a `CommandRegistry`. From the perspective of macro expansion, you can think of the `CommandRegistry` as a dictionary of in-scope macros, and the `Context` as the compile-time state used in expansion. This could gain additional functionality over time as we find more uses for the expansion system.
2019-08-26 21:21:03 +02:00
shellexpand = "1.0.0"
2019-08-30 21:07:07 +02:00
pin-utils = "0.1.0-alpha.4"
2019-09-13 05:44:21 +02:00
num-bigint = { version = "0.2.3", features = ["serde"] }
bigdecimal = { version = "0.1.0", features = ["serde"] }
2019-09-19 06:25:29 +02:00
serde_urlencoded = "0.6.1"
trash = "1.0.0"
2019-10-02 20:56:28 +02:00
regex = "1"
cfg-if = "0.1"
strip-ansi-escapes = "0.1.0"
calamine = "0.16"
2019-11-19 06:46:47 +01:00
umask = "0.1"
2019-12-08 18:56:21 +01:00
futures-util = "0.3.1"
2019-11-04 16:47:03 +01:00
termcolor = "1.0.5"
natural = "0.3.0"
2019-05-23 06:30:43 +02:00
clipboard = {version = "0.5", optional = true }
ptree = {version = "0.2" }
2019-12-08 18:56:21 +01:00
starship = { version = "0.28", optional = true}
2019-12-14 14:27:14 +01:00
heim = {version = "0.0.9", optional = true}
battery = {version = "0.7.5", optional = true}
syntect = {version = "3.2.0", optional = true }
onig_sys = {version = "=69.1.0", optional = true }
crossterm = {version = "0.10.2", optional = true}
futures-timer = {version = "1.0.2", optional = true}
url = {version = "2.1.0", optional = true}
2019-12-10 01:59:13 +01:00
semver = {version = "0.9.0", optional = true}
2019-08-29 01:32:58 +02:00
[features]
default = ["sys", "ps", "textview", "inc", "str"]
stable = ["sys", "ps", "starship-prompt", "textview", "binaryview", "match", "tree", "average", "sum"]
Add Range and start Signature support This commit contains two improvements: - Support for a Range syntax (and a corresponding Range value) - Work towards a signature syntax Implementing the Range syntax resulted in cleaning up how operators in the core syntax works. There are now two kinds of infix operators - tight operators (`.` and `..`) - loose operators Tight operators may not be interspersed (`$it.left..$it.right` is a syntax error). Loose operators require whitespace on both sides of the operator, and can be arbitrarily interspersed. Precedence is left to right in the core syntax. Note that delimited syntax (like `( ... )` or `[ ... ]`) is a single token node in the core syntax. A single token node can be parsed from beginning to end in a context-free manner. The rule for `.` is `<token node>.<member>`. The rule for `..` is `<token node>..<token node>`. Loose operators all have the same syntactic rule: `<token node><space><loose op><space><token node>`. The second aspect of this pull request is the beginning of support for a signature syntax. Before implementing signatures, a necessary prerequisite is for the core syntax to support multi-line programs. That work establishes a few things: - `;` and newlines are handled in the core grammar, and both count as "separators" - line comments begin with `#` and continue until the end of the line In this commit, multi-token productions in the core grammar can use separators interchangably with spaces. However, I think we will ultimately want a different rule preventing separators from occurring before an infix operator, so that the end of a line is always unambiguous. This would avoid gratuitous differences between modules and repl usage. We already effectively have this rule, because otherwise `x<newline> | y` would be a single pipeline, but of course that wouldn't work.
2019-12-04 22:14:52 +01:00
sys = ["heim", "battery"]
ps = ["heim", "futures-timer"]
2019-12-10 03:13:22 +01:00
textview = ["crossterm", "syntect", "onig_sys", "url"]
2019-12-10 01:59:13 +01:00
str = []
Add Range and start Signature support This commit contains two improvements: - Support for a Range syntax (and a corresponding Range value) - Work towards a signature syntax Implementing the Range syntax resulted in cleaning up how operators in the core syntax works. There are now two kinds of infix operators - tight operators (`.` and `..`) - loose operators Tight operators may not be interspersed (`$it.left..$it.right` is a syntax error). Loose operators require whitespace on both sides of the operator, and can be arbitrarily interspersed. Precedence is left to right in the core syntax. Note that delimited syntax (like `( ... )` or `[ ... ]`) is a single token node in the core syntax. A single token node can be parsed from beginning to end in a context-free manner. The rule for `.` is `<token node>.<member>`. The rule for `..` is `<token node>..<token node>`. Loose operators all have the same syntactic rule: `<token node><space><loose op><space><token node>`. The second aspect of this pull request is the beginning of support for a signature syntax. Before implementing signatures, a necessary prerequisite is for the core syntax to support multi-line programs. That work establishes a few things: - `;` and newlines are handled in the core grammar, and both count as "separators" - line comments begin with `#` and continue until the end of the line In this commit, multi-token productions in the core grammar can use separators interchangably with spaces. However, I think we will ultimately want a different rule preventing separators from occurring before an infix operator, so that the end of a line is always unambiguous. This would avoid gratuitous differences between modules and repl usage. We already effectively have this rule, because otherwise `x<newline> | y` would be a single pipeline, but of course that wouldn't work.
2019-12-04 22:14:52 +01:00
inc = ["semver"]
starship-prompt = ["starship"]
2019-12-04 18:51:20 +01:00
binaryview = ["nu_plugin_binaryview"]
match = ["nu_plugin_match"]
tree = ["nu_plugin_tree"]
average = ["nu_plugin_average"]
sum = ["nu_plugin_sum"]
Add Range and start Signature support This commit contains two improvements: - Support for a Range syntax (and a corresponding Range value) - Work towards a signature syntax Implementing the Range syntax resulted in cleaning up how operators in the core syntax works. There are now two kinds of infix operators - tight operators (`.` and `..`) - loose operators Tight operators may not be interspersed (`$it.left..$it.right` is a syntax error). Loose operators require whitespace on both sides of the operator, and can be arbitrarily interspersed. Precedence is left to right in the core syntax. Note that delimited syntax (like `( ... )` or `[ ... ]`) is a single token node in the core syntax. A single token node can be parsed from beginning to end in a context-free manner. The rule for `.` is `<token node>.<member>`. The rule for `..` is `<token node>..<token node>`. Loose operators all have the same syntactic rule: `<token node><space><loose op><space><token node>`. The second aspect of this pull request is the beginning of support for a signature syntax. Before implementing signatures, a necessary prerequisite is for the core syntax to support multi-line programs. That work establishes a few things: - `;` and newlines are handled in the core grammar, and both count as "separators" - line comments begin with `#` and continue until the end of the line In this commit, multi-token productions in the core grammar can use separators interchangably with spaces. However, I think we will ultimately want a different rule preventing separators from occurring before an infix operator, so that the end of a line is always unambiguous. This would avoid gratuitous differences between modules and repl usage. We already effectively have this rule, because otherwise `x<newline> | y` would be a single pipeline, but of course that wouldn't work.
2019-12-04 22:14:52 +01:00
trace = ["nu-parser/trace"]
2019-08-29 01:32:58 +02:00
2019-08-27 23:45:18 +02:00
[dependencies.rusqlite]
version = "0.20.0"
features = ["bundled", "blob"]
2019-05-29 17:26:45 +02:00
[dev-dependencies]
pretty_assertions = "0.6.1"
test-support = { version = "0.1.0", path = "./crates/test-support" }
2019-06-27 06:56:48 +02:00
[build-dependencies]
2019-11-10 18:48:49 +01:00
toml = "0.5.5"
2019-12-08 20:15:14 +01:00
serde = { version = "1.0.103", features = ["derive"] }
2019-12-02 22:14:51 +01:00
nu-build = { version = "0.1.0", path = "./crates/nu-build" }
2019-06-27 06:56:48 +02:00
[lib]
name = "nu"
path = "src/lib.rs"
# Core plugins that ship with `cargo install nu` by default
# Currently, Cargo limits us to installing only one binary
# unless we use [[bin]], so we use this as a workaround
[[bin]]
name = "nu_plugin_core_textview"
path = "crates/nu_plugin_textview/src/main.rs"
required-features = ["textview"]
2019-12-10 01:59:13 +01:00
[[bin]]
name = "nu_plugin_core_inc"
path = "crates/nu_plugin_inc/src/main.rs"
2019-12-10 01:59:13 +01:00
required-features = ["inc"]
[[bin]]
name = "nu_plugin_core_ps"
path = "crates/nu_plugin_ps/src/main.rs"
required-features = ["ps"]
2019-12-10 01:59:13 +01:00
[[bin]]
name = "nu_plugin_core_str"
path = "crates/nu_plugin_str/src/main.rs"
2019-12-10 01:59:13 +01:00
required-features = ["str"]
[[bin]]
name = "nu_plugin_core_sys"
path = "crates/nu_plugin_sys/src/main.rs"
required-features = ["sys"]
# Main nu binary
2019-06-27 06:56:48 +02:00
[[bin]]
name = "nu"
path = "src/main.rs"