Mirrors/clap
2
0
Fork 0
mirror of https://github.com/clap-rs/clap synced 2024-12-12 22:02:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
clap/clap_complete_fig/Cargo.toml

40 lines
1.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_fig"
chore: Release
2023-10-24 18:25:07 +00:00
version = "4.4.2"
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
description = "A generator library used with clap for Fig completion scripts"
repository = "https://github.com/clap-rs/clap/tree/master/clap_complete_fig"
style: Normalize manifests
2022-05-18 15:33:37 +00:00
categories = ["command-line-interface"]
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
keywords = [
style: Normalize manifests
2022-05-18 15:33:37 +00:00
"clap",
"cli",
"completion",
"fig",
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
]
chore: Switch to workspace inheritance
2023-01-09 18:35:54 +00:00
license.workspace = true
edition.workspace = true
rust-version.workspace = true
include.workspace = 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
docs: Add completion changelogs
2022-01-12 17:04:57 +00:00
[package.metadata.docs.rs]
targets = ["x86_64-unknown-linux-gnu"]
[package.metadata.release]
pre-release-replacements = [
{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
[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"] }
clap_complete = { path = "../clap_complete", version = "4.0.0" }
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): update compatible (dev) (#5192) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
2023-11-01 01:03:46 +00:00
snapbox = { version = "0.4.14", features = ["diff"] }
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", "help"] }
Reference in a new issue Copy permalink