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 option to treat array of string arguments as StringArray #55

Closed
wants to merge 12 commits into from

Conversation

jspaleta
Copy link
Contributor

@jspaleta jspaleta commented Jul 13, 2021

Closes #54

Implements an optional attribute Array, that if set changes how multiple call argument stringSlice are processed.
StringSlice -> automatic CSV comma delimited spliting of string value of each call of the argument
StringArray -> no automatic spliting of argument values, each argument call is taken as a separate array entry.

This is implemented as optional, because StringArray use requires more work when using with envvar to ensure you can split the envvar string using an delimiting string of your choice after arguments are parsed, but when strings need to have commas this gives you a way to deal with that.

gohandler_test.go updated with unit tests for both stringSlice and StringArray argument,envvar and annotation override handling.

Note we already have inconsistent handling of annotation overrides relative to argument and envvar handling for existing StringSlice Ref: #56.

@jspaleta jspaleta marked this pull request as ready for review July 14, 2021 00:03
@jspaleta jspaleta requested a review from echlebek July 14, 2021 00:24
Copy link
Contributor

@echlebek echlebek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not clear to me that we should make this optional, which would bifurcate programs using this framework. Some would handle array args in one way, and others would handle them in another way.

I think we need to figure out the long term direction here, weigh the pros and cons, and make a choice one way on the other 😬

@jspaleta
Copy link
Contributor Author

@echlebek If we treat this is a deprecated behavior strategy a bifurcation is allowed for a period of time.
Instead of making StringArray optional, we could possible swtich over to the new StringArray behavior and provide something like a env var that if set would switch back to the deprecated StringSlice behavior, so users impacted by the change could quickly fallback to old behavior until they adjust to new behavior.

@echlebek
Copy link
Contributor

echlebek commented Apr 8, 2022

@jspaleta I intend to pick up this PR and port it to rest on top of the more recent work I've been doing.

echlebek added a commit that referenced this pull request Apr 14, 2022
This commit adds support to SlicePluginConfigOption for using cobra
StringArray, when the type parameter is string. Other types of lists are
not supported by cobra. The behaviour is enabled by setting the
UseCobraStringArray field true.

This option is useful when developers want to support lists of values,
but want to consider values like "1,2" or "1 2" as a single value.

This work is a take on
#55, updated to reflect
the recent changes to the plugin SDK.

Signed-off-by: Eric Chlebek <[email protected]>
@echlebek
Copy link
Contributor

@jspaleta I had too much trouble porting the PR, so I just re-implemented it. Let me know if it makes sense to you.

@jspaleta
Copy link
Contributor Author

closing this one without merging as the new implementation solves the issue

@jspaleta jspaleta closed this Apr 15, 2022
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.

Feature Request: Extend argument parsing support for pflags.StringArray
2 participants