Tracking Issue for 3.x #1037
Comments
kbknapp
added
P1: urgent
E-hard
A full list of deprecations is: * Arg::last -> ArgSettings::Last * Arg::required -> ArgSettings::Required * Arg::require_equals -> ArgSettings::RequireEquals * Arg::allow_hyphen_values -> ArgSettings::AllowHyphenValues * Arg::takes_value -> ArgSettings::TakesValue * Arg::hide_possible_values -> ArgSettings::HidePossibleValues * Arg::hide_default_value -> ArgSettings::HideDefaultValue * Arg::multiple -> ArgSettings::Multiple (see Arg::multiple split) * Arg::multiple -> ArgSettings::MultipleValues (see Arg::multiple split) * Arg::multiple -> ArgSettings::MultipleOccurrences (see Arg::multiple split) * Arg::global -> ArgSettings::Global * Arg::empty_values -> ArgSettings::AllowEmptyValues * Arg::hidden -> ArgSettings::Hidden * Arg::case_insensitive -> ArgSettings::IgnoreCase * Arg::use_delimiter -> ArgSettings::UseDelimiter * Arg::require_delimiter -> ArgSettings::RequireDelimiter * Arg::hide_env_values -> ArgSettings::HideEnvValues * Arg::next_line_help -> ArgSettings::NextLineHelp * Arg::set -> Arg::unset_setting (consistent naming with App) * Arg::unset -> Arg::setting (consistent naming with App) Relates to #1037
A full list of deprecations is: * Arg::last -> ArgSettings::Last * Arg::required -> ArgSettings::Required * Arg::require_equals -> ArgSettings::RequireEquals * Arg::allow_hyphen_values -> ArgSettings::AllowHyphenValues * Arg::takes_value -> ArgSettings::TakesValue * Arg::hide_possible_values -> ArgSettings::HidePossibleValues * Arg::hide_default_value -> ArgSettings::HideDefaultValue * Arg::multiple -> ArgSettings::Multiple (see Arg::multiple split) * Arg::multiple -> ArgSettings::MultipleValues (see Arg::multiple split) * Arg::multiple -> ArgSettings::MultipleOccurrences (see Arg::multiple split) * Arg::global -> ArgSettings::Global * Arg::empty_values -> ArgSettings::AllowEmptyValues * Arg::hidden -> ArgSettings::Hidden * Arg::case_insensitive -> ArgSettings::IgnoreCase * Arg::use_delimiter -> ArgSettings::UseDelimiter * Arg::require_delimiter -> ArgSettings::RequireDelimiter * Arg::hide_env_values -> ArgSettings::HideEnvValues * Arg::next_line_help -> ArgSettings::NextLineHelp * Arg::set -> Arg::unset_setting (consistent naming with App) * Arg::unset -> Arg::setting (consistent naming with App) Relates to #1037
A full list of deprecations is: * Arg::last -> ArgSettings::Last * Arg::required -> ArgSettings::Required * Arg::require_equals -> ArgSettings::RequireEquals * Arg::allow_hyphen_values -> ArgSettings::AllowHyphenValues * Arg::takes_value -> ArgSettings::TakesValue * Arg::hide_possible_values -> ArgSettings::HidePossibleValues * Arg::hide_default_value -> ArgSettings::HideDefaultValue * Arg::multiple -> ArgSettings::Multiple (see Arg::multiple split) * Arg::multiple -> ArgSettings::MultipleValues (see Arg::multiple split) * Arg::multiple -> ArgSettings::MultipleOccurrences (see Arg::multiple split) * Arg::global -> ArgSettings::Global * Arg::empty_values -> ArgSettings::AllowEmptyValues * Arg::hidden -> ArgSettings::Hidden * Arg::case_insensitive -> ArgSettings::IgnoreCase * Arg::use_delimiter -> ArgSettings::UseDelimiter * Arg::require_delimiter -> ArgSettings::RequireDelimiter * Arg::hide_env_values -> ArgSettings::HideEnvValues * Arg::next_line_help -> ArgSettings::NextLineHelp * Arg::set -> Arg::unset_setting (consistent naming with App) * Arg::unset -> Arg::setting (consistent naming with App) Relates to #1037
|
Do we still need |
|
I am not exactly sure about it since I wasn't involved in the project back then. Do you have a link to the commit or PR which removed |
|
I guess I did it. It didn't have any docs and was something like: fn new<T: Into<Key>>(name: T) {}The idea was apparently to allow using anything that's |
|
Isn't |
|
Can you link the commit which removed it? I tried to find it but couldn't. |
|
I cannot find the original commit that removes |
Args are being build via That's funny: I haven't removed it after all Lines 101 to 109 in 37889c6 I clearly remember that I was thinking about removing it as useless, but apparently I didn't make my mind up for it. |
|
Yeah, it was only removed from the docs. That's why we cannot find the commits. |
|
Any chance for another beta release, even if all "beta blockers" aren't fixed yet? I've been waiting to take advantage of #1793 in my pet project. :) |
|
I have no problems with that. @pksunkara what do you think? |
|
I would prefer to finish off fixing the |
|
This The only reason not to release a beta I can think of is - if we wanted to discourage people form depending on unfinished, work-in-progress state of clap, we could avoid any beta releases altogether and require people to use git dependency. That ship has sailed - we have a beta released already, and we've been planning to release several betas all along. Well, not only one. Another reason might be that we wanted to present a "production ready-ish" product, complete (kinda). That would be nice indeed, PR, wow-effect and all that, but our turtle speed of development essentially means that either we do a series of intermediate releases, or there will be no release at all in the near future. It's me at fault more than anybody else, I'm sorry about it, but life takes precedence, and I can't/won't spend much of my time on working on clap right now. Then again, there's @intgr with their contribution. I think they are liable to expect their contribution to become available on crates.io within some reasonable time period. By saying "Let's postpone the release for the sake of having <feature> in the next release, and don't mind that nobody's actively working on it ATM, no deadlines have been set, and it's not immediately clear what to do with it anyway", we're only discouraging future contributors from putting more work in clap. Summarizing all that: given the lack of actual commitment from core contributors for various reasons (which is my polite phrasing for "I am a lazy butt, sorry"), slow pace of development overall, and an explicit request to make the ongoing work available on cartes.io from several people, I don't think there's much point in postponing beta releases on and on. (And I think the release is going to happen one way or another whether we want it or not.) |
|
Okay I will do the beta release tonight. |
|
Those forks were 6 months back and they might have been plenty of unreleased ones which we may never heard off and this is a common thing in the open source world for people to maintain open source forks in private repositories / company domains because it's more "reliable". I don't mind having beta releases, but you need to ask the question at what cost? if it's just to test random unrelated fixes that it just causes more churn to have the releases & ensure everything is proper and working and not regressing between betas. People are not discouraged to contribute whether we have betas or not, people are discouraged to contribute when they see a lack of transparency and they didn't know the state of something because things get closed because "they are fixed on master" or "because their feature is not being seen as acceptable by maintainers or it is worked on or recommended to use another way. There is no "turtle speed of development" (not sure that's even a term because turtles are known to be pretty decent paced irl :P but i understood what you meant) but there's a "effective turtle speed of development". There are too many changes being happening regularly and being merged quickly that it creates enough of churn for people including maintainers to keep track of what's happening. Many times I feel like answering questions or reviewing prs but then i need to check and see what's the reason the changes are made and track as it's refactored multiple times and it's merged quickly enough that there's no point of putting that much of effort. I know most of the (other) contributors haven't been active enough but that's life and clap seems to be a "happy stage" that it may not warrant rushing things. I (and i'm sure the other maintainers) respect your contributions to clap, but if you feel this is just taking up your time and you are not sure of the path ahead, you are free to step down as a maintainer and we won't hold you responsible for anything. |
|
@kbknapp Can you explain the below a bit?
It is the only thing I don't understand from the main post. |
|
There are some The reasoning behind this is so that we didn't have some settings magically affecting the whole application and others only a single command which has caused confusion in the past. |
|
Any chance clap 3 could be released in the current state? Even if this isn't perfect, it is already a significant improvement over the version 2. |
|
A conversation about narrowing the scope for remaining 3.0 work is happening in #2616 |
|
#2869 should cover the rest of this |
UPDATED: 3.0 Milestone
This an internal tracking issue for what I'd like to get done in order to release 3.x. Granted not all of these things must happen in order for a release to happen, but it gives a good idea of what is left to do.
Also, this isn't a fully comprehensive list, or may not even make sense...it's mainly meant as an internal reminder to me.
Once 3.x is out, I should be able to rip through implementing all the feature requests that are piling up
All work is taking place on v3-master, wip work is on v3-dev
3.x-beta Blockers
AppAppSettingsand preferApp::global_settingArgArg::from_usage->Arg::from(&str)validator_osshould returnStringinstead ofOsString)validator_ostakes&OsStr, butvalidatortakesString#1165 (validatortakesStringbutvalidator_ostakes&OsStr)SubCommand->App(stop the facade)AppadditionsApp::get_matches_mut(Lib Blitz Style Summary and Overhaul #950 Lib Blitz naming consistency)App::mut_arg(Add support mutating args once added #458)App::unset_global_setting(Can't unset a global setting #1183)ArgadditionsArg::newArg::settingsArg::unset_settingsimpl From<&str> for Argyaml_rustto 0.4Arg::requires_allnot displaying usage correctly)possible_valueshelp #1160--parameters after the first--are dropped, not allowing nesting of programs? #1161 (Nesting--)value_nameshould complete with file names #1179Arg::raw)Cargo.tomlcode-gen-units = 1in release mode)wrap_helpfeature to README)Indices)ansi_termto 0.11)AllowExternalSubcommands)required(true)with macros)InferSubcommands)structoptArgEnumIntoAppFromArgMatchesClapusagefromArgMatchesterm_sizeto 1.0ARGSshould be first in the sections but last in usage)clap_generate(Move completions / manpage generation to sub-crate #951)3.x-rc Blockers
3.0 Blockers
Items being punted for now (priority after 3.0 release, or if time permits before)
clapfails to compile ifserde_yamlis used, because ofpreserve_orderfeature ofyaml-rust#747) (serde_yamlcan't parse into borrowed structs yet, see Can't use with borrowed values in a struct dtolnay/serde-yaml#94)Arg::from_yaml->serdeAppforserdeclap_generate(Auto-generate manpage, help docs, etc. #552)App::argv(Allow adding "external argv"s to be parsed alongside/before command line #748)App::env_argv(Allow adding "external argv"s to be parsed alongside/before command line #748)clap_derive's moveclap-test.rsto into the srcimpl From<App> for ArgMatchesenv::args_osetc.)impl TryFrom<App> for ArgMatchesFrom<App>AppSettings-> direct use of bitflags (no more facade)The text was updated successfully, but these errors were encountered: