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

Add a note about getopts constraints #99

Merged
merged 1 commit into from
Dec 21, 2020
Merged

Add a note about getopts constraints #99

merged 1 commit into from
Dec 21, 2020

Conversation

KodrAus
Copy link
Contributor

@KodrAus KodrAus commented Jul 19, 2020

Just thinking back to #84, we need to be careful not to change the way arguments are parsed or we could change the behaviour of rustc.

At this point, maybe it’s worth just bumping getopts to 1.0?

@KodrAus
Copy link
Contributor Author

KodrAus commented Jul 19, 2020

cc @rust-lang/libs any thoughts on stabilizing getopts?

@LukasKalbertodt
Copy link
Member

👍 to documenting this strict backwards compatibility somewhere and to releasing as 1.0.

  • This crate is certainly used by many.
  • We already can't break anything about the parsing semantics.
  • The API didn't have any breaking changes since January 2015 (!!), when 0.2.0 was released.
  • Since new, more easy to use (IMO) libraries for CLI args parsing have emerged (clap, structopt), I think the purpose of this library should mainly be stability at this point.

@Amanieu
Copy link
Member

Amanieu commented Jul 19, 2020

My impression is that the recommended way to parse command-line arguments in Rust is to use clap or structopt (which is based on clap). I feel that releasing 1.0 would encourage more people to use this crate, which is something we don't want.

@LukasKalbertodt
Copy link
Member

which is something we don't want.

I agree with that. But I don't think a release necessarily drives people to use this crate. A crate that's used a lot and promises stability but is version 0.x.x seems like it doesn't use semver correctly. Additionally, we can communicate our intentions in the release notes and in the README. And we don't need to publicly announce the release.

@BurntSushi
Copy link
Member

What about bumping to 1.0 and moving it to rust-lang-deprecated?

@KodrAus
Copy link
Contributor Author

KodrAus commented Jul 19, 2020

What about bumping to 1.0 and moving it to rust-lang-deprecated?

Hmm, I guess it's less deprecated and more fixed. Unless @rust-lang/compiler were looking at replacing getopts with something like clap? Or if they're happy to depend on libraries in the deprecated org.

I feel that releasing 1.0 would encourage more people to use this crate, which is something we don't want.

We could add some more docs to the readme pointing users to clap/structopt? It's a little bare at the moment.

@oli-obk
Copy link

oli-obk commented Jul 20, 2020

Is there a reasonable path for rustc to move to clap/structopt? If so, we could remove this dependency entirely in favour of the community crate.

@KodrAus
Copy link
Contributor Author

KodrAus commented Jul 20, 2020

@oli-obk I’m not sure to be honest but that sounds like something worth pursuing!

@KodrAus
Copy link
Contributor Author

KodrAus commented Dec 21, 2020

Since this PR doesn't actually do anything with stabilization I'll go ahead and merge this disclaimer.

@KodrAus KodrAus merged commit 985dda9 into master Dec 21, 2020
@KodrAus KodrAus deleted the KodrAus-patch-1 branch December 21, 2020 08:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants