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

65 lines
2.4 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-09-20 21:30:29 +00:00
version = "4.0.0-rc.1"
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]
chore: Update version The main goal is to reduce the risk of people developing on the wrong release, assuming they are using something like starship to raise the visibility of the crate version.
2022-07-24 02:43:35 +00:00
clap = { path = "../", version = "4.0.0-alpha.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: Update dependencies
2022-09-01 12:09:32 +00:00
snapbox = { version = "0.3", features = ["diff"] }
test(complete): Option to verify examples
2022-04-27 13:54:39 +00:00
# Cutting out `filesystem` feature
trycmd = { version = "0.13", default-features = false, features = ["color-auto", "diff", "examples"] }
feat(help): Break out help feature flag This removes auto-generated help, saving about 50 KiB.
2022-09-19 16:54:06 +00:00
clap = { path = "../", version = "4.0.0-alpha.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