Is this an abandoned project? about go-flags

[peterebden]

I was just focusing on that the 16 latest commits from jessevdk:master has not merged into your repo yet, so I personally won't consider such fork official.

Fair enough :) If we find time it would be useful for us to check those 16 commits and see if we have any issues incorporating them (hopefully / probably not) and then see whether we can turn our changes into a set of pull requests here - that'd make it clear how the two have diverged. I'm hopeful that the differences are not that profound.

[errordeveloper]

@johnnybubonic it probably would, albeit all of my project that use this library right now are quite simple, and I don't have a desire to write a comlicated CLI any time soon. When I mentioned that, I was thinking of some of the things I had to do in ekstl, one example would be some default values being depedand on values of other flags.

[suntong]

I define my cli interface at higher level abstractly within a .yaml file, and let the easygen to generate different cli files for different packages for me (from the same .yaml file). Details at:

https://github.com/go-easygen/easygen/wiki/Docs:-Command-line-flag-handling-code-auto-generation

BTW, for anyone who don't have the time or energy to jump-ship to another project, take a look at
https://github.com/go-easygen/go-flags

That's the project that I forked, and then looked into every other forks, with or without PR sending over to the official repo, and collected all possible enhancements into a single repo:

check it out.

[FrankDMartinez]

My two cents: I used this package on one project and it was okay; on another project I used https://github.com/alexflint/go-arg and I haven't looked back because it's so easy to use it almost feels "too easy".

[errordeveloper]

It looks like there is fork that had a release last month (https://github.com/thought-machine/go-flags/releases/tag/v1.6.1).

https://github.com/thought-machine/go-flags

Perhaps @thought-machine folks could make their fork official? /cc @peterebden @samwestmoreland

[suntong]

"This branch is 20 commits ahead, 16 commits behind jessevdk:master"

Seems that he's only scratching his own itches, not too care about the latest development on jessevdk:master side, :(

[peterebden]

When I created that fork, I wasn't planning for it to take over from this repo; we've used this library extensively and still are very fond of it, ideally I'd like development to come back here. We have done some more work on that fork to facilitate our own needs, particularly Sam's done work on it recently for some fairly specific use cases we have (we're doing some programmatic building of flags objects which I get the impression is not very common elsewhere), although I don't think there is any fundamental reason that can't be merged back.

I'm not sure if we would have the time to be good stewards of the project - maybe. But it would be nice to hear what @jessevdk thinks, I definitely don't want it to look like we're trying to muscle in and take this away :)

Seems that he's only scratching his own itches, not too care about the latest development on jessevdk:master side, :(

I think that is a little unfair. There was a period when this repo went pretty quiet (hence why we forked, it's painful to keep stacking up patches or use replace directives) but before that I sent quite a few changes back; currently #299 is still waiting from several years back. Later there was some more activity here, but honestly we've just been busy on other things and haven't gotten back around to trying to upstream things and potentially un-fork.

[suntong]

I think that is a little unfair.

sorry about that -- I didn't mean to hurt you personally or your overall contributions.

I was just focusing on that the 16 latest commits from jessevdk:master has not merged into your repo yet, so I personally won't consider such fork official.

It's only my personal view and I'm sorry to have expressed that bluntly.

The reason for all this is that, I do love this project, and think it is still the best I found so far. Just I'm sad to see the maintenance/development side stopped.

[errordeveloper]

we're doing some programmatic building of flags objects which I get the impression is not very common elsewhere

I think that is quite reasonable, it's something that one can do with either stdlib's flag or the likes of cobra. I would certainly like to be able to set descriptions and defaults dynamically, not sure if this library supports that right now.

[errordeveloper]

Has anyone tried contacting @jessevdk via email or other channels?

[borud]

I think it is safe to assume that this project has been abandoned.

[errordeveloper]

Sounds like a fork is overdue 😄
...well, I'm using @thought-machine one already.

[johnnybubonic]

we're doing some programmatic building of flags objects which I get the impression is not very common elsewhere

I think that is quite reasonable, it's something that one can do with either stdlib's flag or the likes of cobra. I would certainly like to be able to set descriptions and defaults dynamically, not sure if this library supports that right now.

@errordeveloper does Parser.Command.Group.AddOption() scratch that itch for you? (See Option.Description.)

[maxlandon]

Hello everyone,
I've developed a new library mostly based on octago/sflags, and aiming to provide as much retro-compatibility with go-flags. My original work was to enhance go-flags, but I ended shifting my approach in order to leverage the now-battle-tested cobra library.
This allows to bring a wide array of possibilities, especially as far as CLI functionality (like completions) is concerned. You might be interested by this !
Goes with documentation, and a page describing the differences with go-flags.
Link to repo: https://github.com/reeflective/flags.

[errordeveloper]

@maxlandon thanks for sharing, will have a look! As much as I tend to dislike cobra for complexity, I can see how it might be a pragmatic choice and allow for incremental changes in some projects (does your lib implementation allow that?).

[suntong]

As much as I tend to dislike cobra for complexity,

Yeah, that's exactly the reason I don't like it either.

I can see how it might be a pragmatic choice and allow for incremental changes in some projects

Another option is, instead of relying on a single tool/package to do the migration, I define my cli interface at higher level abstractly within a .yaml file, and let the easygen to generate different cli files for different packages for me (from the same .yaml file). Details at:

https://github.com/go-easygen/easygen/wiki/Docs:-Command-line-flag-handling-code-auto-generation

[maxlandon]

@maxlandon thanks for sharing, will have a look! As much as I tend to dislike cobra for complexity, I can see how it might be a pragmatic choice and allow for incremental changes in some projects (does your lib implementation allow that?).

Well we all agree that cobra being somewhat made as to reach to greatest number of use cases, it has its complexities. However, I must say that I find its defaults to be rather sane, and that you don't have to care about most of the possible fields/settings of a cobra command (or its flags) in order to make it work.

To answer your question:
So if you'll read the doc you'll see that I mention that there are cases where developers need/want to access the command tree state from either:

• Within their command runners
• After generating commands from structs, but before running commands (when you want to modify behavior, or when you must assign stuff that is dynamic (ex: a list of valid choices that is determined at runtime), which therefore cannot be done via struct tags.

So yes basically there are a couple reasons why I chose to generate structs into cobra commands:

• It allows to rely on a battle-tested library for parsing command lines, and executing them, which is that much less to take care of in the flags library.
• It allows to set various additional commands' settings/behaviors.
• We continually benefit from improvements in the said libraries.
• The flags library also makes use of another completion engine that is specifically designed around cobra commands, and a very powerful one: checkout https://github.com/rsteube/carapace. This is an example of how we can benefit from a wide array of CLI functionality at almost no cost, cross-platform and cross-shell, by parsing structs into cobra commands.
• Also, the cobra model is very uniform: the root parser is also a command.
  -Finally, executing a CLI based on a cobra tree is as simple as cmd.Execute() after the ˋGenerate(myStruct{})` call.
• In other words, and this where I ended up being really compelled by the idea of generating into cobra commands: if you're fine with your struct tags specs, you don't even need to know that you are actually running a cobra command !

Additionally:

• go-flags only supports INI configuration. Down the road, basing the flags library on cobra will allow to use viper, which will significantly expand the realm of possibilities as far as flags configuration is concerned, but also many other things (stay tuned on that).

[denisvmedia]

@suntong is there a reason you didn't use fork functionality of GitHub? (just wondering)

[suntong]

@suntong is there a reason you didn't use fork functionality of GitHub? (just wondering)

Lots of reasons, but in summary, I'm doing it in respectful of the original author. Here are the top major reasons.

• There are 15 pending PRs here in this repo, I don't know the reason why the original author didn't take them.
• Furthermore, I went beyond the pending PRs here, and looked into every other forks with meaningful changes, and take them. I don't know if the original author would agree me on that or not.
• I've added my own personal changes into https://github.com/go-easygen/go-flags/ too, and again I don't know if the original author would agree on those changes or not.
• What are above reasons to do with using the fork functionality of GitHub? -- Every single commit that I made to my repo would be pushed here, regardless the original author agrees or not. I.e., the fork functionality of GitHub would not be a help in such situation, but a barrier to overcome instead -- if the original author comes back, he would most probably do git cherry pick according to his will anyway. I.e., nothing is lost, but the freedom is all his.

[suntong]

on another project I used https://github.com/alexflint/go-arg and I haven't looked back because it's so easy to use it almost feels "too easy".

Wow, indeed! Thanks for the recommendation!

[maxlandon]

https://github.com/alexflint/go-arg#subcommands

Having to do switch statements on all commands to find which one is active is clearly a regression as compared with all other libraries using struct parsing. Same goes with their validation mechanism.

Although I am yet another one having written a struct-based CLI library, I must say its a shame that we actually end up with tens of different libraries which only differ in the tag names to use, and one or two conventions. The net result is just:

• 90% of them either lack at least a half of required functionality (completions, validations at no cost, easy grouping and flag functionality, etc...).
• All of them are busy maintaining a parsing/command code of their own, while libs like cobra have solved this since 5 years (and I can't hear the "we want stdlib" stuff, it just does not hold with cobra having only 2 imports).
• At least compared to go-flags, most of them are just pure regression. IMHO only the kong CLI library is not.
• All of those libs (including go-arg), will end up completely useless for complex, highly nested CLIs, for just no reason other than "I want to keep my church up because I like it". I know everyone has his tastes/preferences/automatism, but when it just results in 10-times duplicated codebases + 3 cosmetic changes, personal tastes just boil down to waste for all.

(Disclaiming that my own lib translates structs to cobra stuff, so I might look biased, but again, maintaining command/flag parsing code is just a complete waste of time: there are so many stuff to be done outside of that).