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

feature: support provider of flags urfave/cli v3 #333

Open
YvanDaSilva opened this issue Nov 12, 2024 · 3 comments
Open

feature: support provider of flags urfave/cli v3 #333

YvanDaSilva opened this issue Nov 12, 2024 · 3 comments

Comments

@YvanDaSilva
Copy link

YvanDaSilva commented Nov 12, 2024

Feature Request

Hello,

urfave/cli (https://github.com/urfave/cli) is a fairly popular go cli toolkit.
It provides the ability to create a hierarchy of commands and attach flags reading to those commands.

In UNIX, it's often popular to use flags to pass (enforce) configurations via flags. This can be useful to avoid the need of a config file or simply to bypass a defaults, file or env configuration.

I see that there is already a PR to support urfave/cli/v2, however v3 is on the verge of being released and as such I think it would be great if we could provide support for both versions, hence this feature request.

I will gladly create the provider for v3 if @knadh is okay with this feature being added.

@joicemjoseph
Copy link

Hi @YvanDaSilva,
Author of #330 here. Thank you very much for raising this issue.
It will be really nice koanf having support for all versions of urfave/cli.

At present, v1, v2 are widely used and actively maintained, like you mentioned, v3 is nearing its released.

We gave some thoughts on how koanf provider for urfave/cli can be maintained. We considered the following approaches.

  1. create a urfave/cli provider library in a separate namespace, version it according to the urfave/cli library version.
    eg: joicemjoseph/cliflag with tagged v1 for urfave/cli/v1, v2 for urfave/cli/v2 and so on.
    We decided against this approach as it would reduce discoverability and lose the benefits of official support by being outside the main repository.

  2. create a submodule in the existing structure, like providers/cliflag, but use sub-directories for each version as follows providers/cliflag/v1, providers/cliflag/v2 and so on. we tried out this method here, with proper tagging. But it didnt worked. Both the versions didn't resolved [1][2][3].
    We left that option as well. Even if we make it work, it will be confusing with go semantic versioning, possible conflict with directory name and tag.

  3. Third option we came across is, maintain 3 different submodules of urfave/cli
    eg: providers/cliflagv1 for urfave/cli/v1, providers/cliflagv2 for urfave/cli/v2 and so on.

I'd appreciate your thoughts on these approaches, particularly the third option which I think sensible.

@joicemjoseph
Copy link

hi, @YvanDaSilva can you share your feedback ?

@YvanDaSilva
Copy link
Author

hi, @YvanDaSilva can you share your feedback ?

Hello and sorry,
I've been extremely busy lately.
I will try to review your comments but I do think that anything will better than nothing, and that we can change design over time if needed. So let me not be a blocker for any changes.

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

No branches or pull requests

2 participants