proposal: cmd: Use getopt/posix style flags in golang 2.0 #60474
Comments
|
for cmd/go this is a major breaking change to people's workflows i can't see this behind adopted. the external libraries work fine as external libraries, see https://go.dev/doc/faq#x_in_std |
|
Oh geez, I'm sorry, I might have misunderstood-- I thought the point of a golang 2.0 proposal was indeed about things we didn't do as well as we could, and about breaking changes. Aren't we supposed to have a discussion about it here first? |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
To be clear, while we discuss language/breaking changes under the framework for Go 2, they still need a reasonable path to implementation. For language changes, we now have #56986 and #57001. For packages, there was no clear outcome from #48287. That said, a breaking change from the standard library represents wide ranging ecosystem churn, and will only usually be considered if there are serious defects in the existing APIs. It has a very high bar to clear, and we expect the appropriate level of detail and thought to go into such proposals. Any such proposal also needs to discuss how the existing version will be maintained, we don't want to end up maintaining 2 separate implementations. For example, the possible encoding/json refresh addresses performance issues, while ensuring v1 can be implemented in terms of v2. Finally, for additions to the standard library, it needs to answer https://go.dev/doc/faq#x_in_std . Why is it a good use of the Go project's limited resources to maintain such a library, and why would an external packages be insufficient. See also #12251 |
|
The deviation from POSIX flag handling was an intentional choice for Go. We would make the same choice again. |
@rsc I'd love to understand why. I don't know that it has ever been received as a positive thing. In any case, just wanted to help with a proposal and to see it fairly considered. The fact that some seankhliao person has been unilaterally closing proposals they don't like isn't a good look or a nice feeling. I haven't looked into it before, but apparently they have a history of doing so. Is that the expected process? |
Dear golang community,
I propose that for golang 2.0 we switch away from the old-style "flag" parsing and move to the more common, modern getopt style variant. That way
go buildand friends can work how most people expect a modern CLI application to work.There are many subtleties, and I certainly don't want to bike-shed on that; in short, let's move to a version that let's you have long and short opts so that
-abcbe equivalent to-a -b -cand--helpand--example-long-optionare functional.While I'm aware that the "flag" package does support doing
--something, the standard tools don't use this approach. At a minimum, we should at least add the additional double dash variant flags to the current tooling.There are many current implementations that do this already. The most popular are likely https://github.com/urfave/cli and https://github.com/spf13/cobra although these two incorporate many extra features which are not necessarily useful for golang.
For golang's usage, it might be sensible to implement a very small subset of what's really need, and make that available as a core library for the 80% of people who just want a few simple args.
Thank you for considering my proposal!
The text was updated successfully, but these errors were encountered: