Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Issue for 3.x #1037

Closed
72 of 87 tasks
kbknapp opened this issue Aug 21, 2017 · 19 comments
Closed
72 of 87 tasks

Tracking Issue for 3.x #1037

kbknapp opened this issue Aug 21, 2017 · 19 comments
Assignees
Labels
E-hard Call for participation: Experience needed to fix: Hard / a lot
Milestone

Comments

@kbknapp
Copy link
Member

kbknapp commented Aug 21, 2017

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

  • = not started
  • = complete

3.x-beta Blockers

3.x-rc Blockers

3.0 Blockers

  • 3.0 Release
    • Double check all docs
    • Double check all examples
    • Double Check readme
    • Double check examples on clap.rs
    • Changelog
    • Clippy Run
    • Rustfmt Run
    • Spell Check Docs
    • Blog Post

Items being punted for now (priority after 3.0 release, or if time permits before)

@kbknapp kbknapp added the W: 3.x label Aug 21, 2017
@kbknapp kbknapp added this to the 3.0 milestone Aug 21, 2017
@kbknapp kbknapp mentioned this issue Jan 26, 2018
@kbknapp kbknapp added P1: urgent E-hard Call for participation: Experience needed to fix: Hard / a lot labels Jan 26, 2018
@kbknapp kbknapp self-assigned this Jan 26, 2018
kbknapp added a commit that referenced this issue Jan 31, 2018
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
kbknapp added a commit that referenced this issue Jan 31, 2018
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
kbknapp added a commit that referenced this issue Feb 3, 2018
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
@kbknapp kbknapp removed this from the 3.0 milestone Jul 22, 2018
@pksunkara pksunkara added this to the 3.0 milestone Feb 3, 2020
@pickfire
Copy link
Contributor

Do we still need Arg::new(), didn't we remove it last time?

@pksunkara
Copy link
Member

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 Arg::new?

@CreepySkeleton
Copy link
Contributor

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 Into<Key> (clap's synonym for hashing), but I really doubt this could be useful. For what?

@pksunkara
Copy link
Member

Isn't Arg::new the thing used for building args?

@pksunkara
Copy link
Member

Can you link the commit which removed it? I tried to find it but couldn't.

@pickfire
Copy link
Contributor

2b3d3fd

CHANGELOG https://github.com/clap-rs/clap/blob/6422930a1864fdfd32b15f01e76bc0aa428cdd52/CHANGELOG.md#breaking-changes-2

I cannot find the original commit that removes Arg::new.

@CreepySkeleton
Copy link
Contributor

Isn't Arg::new the thing used for building args?

Args are being build via Arg::with_name and Arg::from (Arg::from_usage and Arg::clone in 2.x).

That's funny: I haven't removed it after all

clap/src/build/arg/mod.rs

Lines 101 to 109 in 37889c6

/// @TODO @p2 @docs @v3-beta1: Write Docs
pub fn new<T: Key>(t: T) -> Self {
Arg {
id: t.key(),
disp_ord: 999,
unified_ord: 999,
..Default::default()
}
}

I clearly remember that I was thinking about removing it as useless, but apparently I didn't make my mind up for it.

@pickfire
Copy link
Contributor

Yeah, it was only removed from the docs. That's why we cannot find the commits.

@intgr
Copy link
Contributor

intgr commented Sep 15, 2020

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. :)

@CreepySkeleton
Copy link
Contributor

I have no problems with that. @pksunkara what do you think?

@pksunkara
Copy link
Member

I would prefer to finish off fixing the multiple issue and then doing the beta.

@CreepySkeleton
Copy link
Contributor

This multiple thing is not going to happen this week. My free time is severely limited at the moment, and the first thing I'm about to start working on is globals (I promised it back in May, dammit) and empty values (almost finished and been brewing for two months).

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.)

@pksunkara
Copy link
Member

Okay I will do the beta release tonight.

@Dylan-DPC-zz
Copy link

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.

@pksunkara
Copy link
Member

@kbknapp Can you explain the below a bit?

(Re)Move inherently global AppSettings and prefer App::global_setting

It is the only thing I don't understand from the main post.

@kbknapp
Copy link
Member Author

kbknapp commented Sep 28, 2020

There are some AppSettings which don't make sense in a non global context, meaning using for only a single subcommand doesn't make sense. GlobalVersion is one example, but there are several. These settings were designed with the whole application in mind. The intent behind that phrase you quoted was to move away from AppSettings which only make sense in a global context and instead use variations which only apply to a single command, but allow the user to select App::global_setting if they preferred applying the settings to the whole application.

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.

@sylvestre
Copy link

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.

@epage
Copy link
Member

epage commented Aug 23, 2021

A conversation about narrowing the scope for remaining 3.0 work is happening in #2616

@epage
Copy link
Member

epage commented Oct 13, 2021

#2869 should cover the rest of this

@epage epage closed this as completed Oct 13, 2021
@pksunkara pksunkara unpinned this issue Oct 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-hard Call for participation: Experience needed to fix: Hard / a lot
Projects
None yet
Development

No branches or pull requests

8 participants