Mirrors/clap
2
0
Fork 0
mirror of https://github.com/clap-rs/clap synced 2024-11-10 14:54:15 +00:00
Code Issues Projects Releases Packages Wiki Activity
clap/clap_complete/Cargo.toml

65 lines
2.3 KiB
TOML
Raw Normal View History

fix(complete): Give crates more specific names `clap_generate` originally intended to be "generate anything". With `fig`, we already broke one part out. With #3174's man support, we are also looking at keeping it separate: - More freedom to iterate on the API - Uniqueness (and potential weight) of its dependencies - man generation is normally more for distribution while completions are a mix of being distributed with the app or the app generating the completions (which will be exacerbated if we move most completion parsing logic to be in Rust) So `clap_generate` is having a lot more limited of a role than the original name conveys. I worry the generic name will be a hindrance to people discovering and using it (yes, documentation can help but there are limits). I hesitated because we are on the verge of releasing 3.0. However, doing it even later will be even more disruptive because more people will be using it (crates.io lists ~70 people using `clap_generate`). To ease things, we are still releasing `clap_generate` as a wrapper around `clap_complete`.
2021-12-31 17:59:15 +00:00
[package]
name = "clap_complete"
chore: Release
2022-12-22 18:40:15 +00:00
version = "4.0.7"
style: Normalize manifests
2022-05-18 15:33:37 +00:00
description = "Generate shell completion scripts for your clap::Command"
repository = "https://github.com/clap-rs/clap/tree/master/clap_complete"
categories = ["command-line-interface"]
keywords = [
"clap",
"cli",
"completion",
"bash",
]
license = "MIT OR Apache-2.0"
fix: Switch to 2021 edition
2022-05-18 15:35:30 +00:00
edition = "2021"
chore: Bump MSRV to 1.60.0 While at it, this cleans up all of the features. For some reason, I couldn't do `dep:clap_derive` though.
2022-08-11 02:32:04 +00:00
rust-version = "1.60.0" # MSRV
fix(complete): Give crates more specific names `clap_generate` originally intended to be "generate anything". With `fig`, we already broke one part out. With #3174's man support, we are also looking at keeping it separate: - More freedom to iterate on the API - Uniqueness (and potential weight) of its dependencies - man generation is normally more for distribution while completions are a mix of being distributed with the app or the app generating the completions (which will be exacerbated if we move most completion parsing logic to be in Rust) So `clap_generate` is having a lot more limited of a role than the original name conveys. I worry the generic name will be a hindrance to people discovering and using it (yes, documentation can help but there are limits). I hesitated because we are on the verge of releasing 3.0. However, doing it even later will be even more disruptive because more people will be using it (crates.io lists ~70 people using `clap_generate`). To ease things, we are still releasing `clap_generate` as a wrapper around `clap_complete`.
2021-12-31 17:59:15 +00:00
include = [
chore: Fix manifest
2022-04-30 11:37:57 +00:00
"build.rs",
"src/**/*",
"Cargo.toml",
"LICENSE*",
"README.md",
"benches/**/*",
"examples/**/*"
fix(complete): Give crates more specific names `clap_generate` originally intended to be "generate anything". With `fig`, we already broke one part out. With #3174's man support, we are also looking at keeping it separate: - More freedom to iterate on the API - Uniqueness (and potential weight) of its dependencies - man generation is normally more for distribution while completions are a mix of being distributed with the app or the app generating the completions (which will be exacerbated if we move most completion parsing logic to be in Rust) So `clap_generate` is having a lot more limited of a role than the original name conveys. I worry the generic name will be a hindrance to people discovering and using it (yes, documentation can help but there are limits). I hesitated because we are on the verge of releasing 3.0. However, doing it even later will be even more disruptive because more people will be using it (crates.io lists ~70 people using `clap_generate`). To ease things, we are still releasing `clap_generate` as a wrapper around `clap_complete`.
2021-12-31 17:59:15 +00:00
]
style: Normalize manifests
2022-05-18 15:33:37 +00:00
[package.metadata.docs.rs]
targets = ["x86_64-unknown-linux-gnu"]
fix(complete): Give crates more specific names `clap_generate` originally intended to be "generate anything". With `fig`, we already broke one part out. With #3174's man support, we are also looking at keeping it separate: - More freedom to iterate on the API - Uniqueness (and potential weight) of its dependencies - man generation is normally more for distribution while completions are a mix of being distributed with the app or the app generating the completions (which will be exacerbated if we move most completion parsing logic to be in Rust) So `clap_generate` is having a lot more limited of a role than the original name conveys. I worry the generic name will be a hindrance to people discovering and using it (yes, documentation can help but there are limits). I hesitated because we are on the verge of releasing 3.0. However, doing it even later will be even more disruptive because more people will be using it (crates.io lists ~70 people using `clap_generate`). To ease things, we are still releasing `clap_generate` as a wrapper around `clap_complete`.
2021-12-31 17:59:15 +00:00
[package.metadata.release]
pre-release-replacements = [
docs: Add completion changelogs
2022-01-12 17:04:57 +00:00
{file="CHANGELOG.md", search="Unreleased", replace="{{version}}", min=1},
{file="CHANGELOG.md", search="\\.\\.\\.HEAD", replace="...{{tag_name}}", exactly=1},
{file="CHANGELOG.md", search="ReleaseDate", replace="{{date}}", min=1},
{file="CHANGELOG.md", search="<!-- next-header -->", replace="<!-- next-header -->\n## [Unreleased] - ReleaseDate\n", exactly=1},
{file="CHANGELOG.md", search="<!-- next-url -->", replace="<!-- next-url -->\n[Unreleased]: https://github.com/clap-rs/clap/compare/{{tag_name}}...HEAD", exactly=1},
fix(complete): Give crates more specific names `clap_generate` originally intended to be "generate anything". With `fig`, we already broke one part out. With #3174's man support, we are also looking at keeping it separate: - More freedom to iterate on the API - Uniqueness (and potential weight) of its dependencies - man generation is normally more for distribution while completions are a mix of being distributed with the app or the app generating the completions (which will be exacerbated if we move most completion parsing logic to be in Rust) So `clap_generate` is having a lot more limited of a role than the original name conveys. I worry the generic name will be a hindrance to people discovering and using it (yes, documentation can help but there are limits). I hesitated because we are on the verge of releasing 3.0. However, doing it even later will be even more disruptive because more people will be using it (crates.io lists ~70 people using `clap_generate`). To ease things, we are still releasing `clap_generate` as a wrapper around `clap_complete`.
2021-12-31 17:59:15 +00:00
{file="README.md", search="github.com/clap-rs/clap/blob/[^/]+/", replace="github.com/clap-rs/clap/blob/{{tag_name}}/", exactly=4, prerelease = true},
]
[lib]
bench = false
[dependencies]
fix: Require release versions of clap
2022-10-18 19:36:44 +00:00
clap = { path = "../", version = "4.0.0", default-features = false, features = ["std"] }
chore: Release
2022-09-20 21:28:27 +00:00
clap_lex = { path = "../clap_lex", version = "0.3.0", optional = true }
feat(complete): Minimal rust-completion Inspired by argcomplete, this provides Rust-implemented completions - Only bash for now - No subcommand support - No flag value support - No special settings support - No handling of positions within positionals - No prioritizing of required or removing of conflicts (including self-conflicts)
2022-04-15 21:08:11 +00:00
is_executable = { version = "1.0.1", optional = true }
os_str_bytes = { version = "6.0", default-features = false, features = ["raw_os_str"], optional = true }
feat(complete): Look up partial matches
2022-04-27 19:19:35 +00:00
pathdiff = { version = "0.2.1", optional = true }
feat(complete): Minimal rust-completion Inspired by argcomplete, this provides Rust-implemented completions - Only bash for now - No subcommand support - No flag value support - No special settings support - No handling of positions within positionals - No prioritizing of required or removing of conflicts (including self-conflicts)
2022-04-15 21:08:11 +00:00
shlex = { version = "1.1.0", optional = true }
unicode-xid = { version = "0.2.2", optional = true }
fix(complete): Give crates more specific names `clap_generate` originally intended to be "generate anything". With `fig`, we already broke one part out. With #3174's man support, we are also looking at keeping it separate: - More freedom to iterate on the API - Uniqueness (and potential weight) of its dependencies - man generation is normally more for distribution while completions are a mix of being distributed with the app or the app generating the completions (which will be exacerbated if we move most completion parsing logic to be in Rust) So `clap_generate` is having a lot more limited of a role than the original name conveys. I worry the generic name will be a hindrance to people discovering and using it (yes, documentation can help but there are limits). I hesitated because we are on the verge of releasing 3.0. However, doing it even later will be even more disruptive because more people will be using it (crates.io lists ~70 people using `clap_generate`). To ease things, we are still releasing `clap_generate` as a wrapper around `clap_complete`.
2021-12-31 17:59:15 +00:00
[dev-dependencies]
chore(deps): bump snapbox from 0.3.3 to 0.4.0 Bumps [snapbox](https://github.com/assert-rs/trycmd) from 0.3.3 to 0.4.0. - [Release notes](https://github.com/assert-rs/trycmd/releases) - [Changelog](https://github.com/assert-rs/trycmd/blob/main/CHANGELOG.md) - [Commits](https://github.com/assert-rs/trycmd/compare/snapbox-v0.3.3...snapbox-v0.4.0) --- updated-dependencies: - dependency-name: snapbox dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
2022-10-01 18:58:27 +00:00
snapbox = { version = "0.4", features = ["diff"] }
test(complete): Option to verify examples
2022-04-27 13:54:39 +00:00
# Cutting out `filesystem` feature
chore(deps): update dev
2022-12-01 21:38:13 +00:00
trycmd = { version = "0.14.5", default-features = false, features = ["color-auto", "diff", "examples"] }
fix: Require release versions of clap
2022-10-18 19:36:44 +00:00
clap = { path = "../", version = "4.0.0", default-features = false, features = ["std", "derive", "help"] }
fix(complete): Give crates more specific names `clap_generate` originally intended to be "generate anything". With `fig`, we already broke one part out. With #3174's man support, we are also looking at keeping it separate: - More freedom to iterate on the API - Uniqueness (and potential weight) of its dependencies - man generation is normally more for distribution while completions are a mix of being distributed with the app or the app generating the completions (which will be exacerbated if we move most completion parsing logic to be in Rust) So `clap_generate` is having a lot more limited of a role than the original name conveys. I worry the generic name will be a hindrance to people discovering and using it (yes, documentation can help but there are limits). I hesitated because we are on the verge of releasing 3.0. However, doing it even later will be even more disruptive because more people will be using it (crates.io lists ~70 people using `clap_generate`). To ease things, we are still releasing `clap_generate` as a wrapper around `clap_complete`.
2021-12-31 17:59:15 +00:00
feat(complete): Minimal rust-completion Inspired by argcomplete, this provides Rust-implemented completions - Only bash for now - No subcommand support - No flag value support - No special settings support - No handling of positions within positionals - No prioritizing of required or removing of conflicts (including self-conflicts)
2022-04-15 21:08:11 +00:00
[[example]]
name = "dynamic"
required-features = ["unstable-dynamic"]
fix(complete): Give crates more specific names `clap_generate` originally intended to be "generate anything". With `fig`, we already broke one part out. With #3174's man support, we are also looking at keeping it separate: - More freedom to iterate on the API - Uniqueness (and potential weight) of its dependencies - man generation is normally more for distribution while completions are a mix of being distributed with the app or the app generating the completions (which will be exacerbated if we move most completion parsing logic to be in Rust) So `clap_generate` is having a lot more limited of a role than the original name conveys. I worry the generic name will be a hindrance to people discovering and using it (yes, documentation can help but there are limits). I hesitated because we are on the verge of releasing 3.0. However, doing it even later will be even more disruptive because more people will be using it (crates.io lists ~70 people using `clap_generate`). To ease things, we are still releasing `clap_generate` as a wrapper around `clap_complete`.
2021-12-31 17:59:15 +00:00
[features]
default = []
chore: Bump MSRV to 1.60.0 While at it, this cleans up all of the features. For some reason, I couldn't do `dep:clap_derive` though.
2022-08-11 02:32:04 +00:00
unstable-dynamic = ["dep:clap_lex", "dep:shlex", "dep:unicode-xid", "dep:os_str_bytes", "clap/derive", "dep:is_executable", "dep:pathdiff"]
fix(complete): Give crates more specific names `clap_generate` originally intended to be "generate anything". With `fig`, we already broke one part out. With #3174's man support, we are also looking at keeping it separate: - More freedom to iterate on the API - Uniqueness (and potential weight) of its dependencies - man generation is normally more for distribution while completions are a mix of being distributed with the app or the app generating the completions (which will be exacerbated if we move most completion parsing logic to be in Rust) So `clap_generate` is having a lot more limited of a role than the original name conveys. I worry the generic name will be a hindrance to people discovering and using it (yes, documentation can help but there are limits). I hesitated because we are on the verge of releasing 3.0. However, doing it even later will be even more disruptive because more people will be using it (crates.io lists ~70 people using `clap_generate`). To ease things, we are still releasing `clap_generate` as a wrapper around `clap_complete`.
2021-12-31 17:59:15 +00:00
debug = ["clap/debug"]
Reference in a new issue Copy permalink