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:(issue_269) Allow external package flag definitions #1540

Merged
merged 5 commits into from Oct 28, 2022

Conversation

dearchap
Copy link
Contributor

What type of PR is this?

(REQUIRED)

  • feature

What this PR does / why we need it:

(REQUIRED)

Which issue(s) this PR fixes:

(REQUIRED)

Fixes #269

Special notes for your reviewer:

(fill-in or delete this section)

Testing

go test -run=TestApp_FlagsFromExtPackage

(fill-in or delete this section)

Release Notes

(REQUIRED)


@dearchap dearchap requested a review from a team as a code owner October 21, 2022 00:52
@dearchap dearchap changed the title Issue 269 Feature:(issue_269) Allow external package flag definitions Oct 21, 2022
app.go Outdated
Comment on lines 202 to 203
if !strings.HasPrefix(f.Name, "test.") {
a.Flags = append(a.Flags, extFlag{f})
Copy link
Member

Choose a reason for hiding this comment

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

I'm good with specifically ignoring flags with "test." prefix in this implementation 👍🏼 I looked briefly and couldn't find any exported code that could be used to get this prefix from go libraries 🤷🏼

What's the reasoning behind using a extFlag{f} instead of &extFlag{f} and having the extFlag methods use a pointer receiver?

Copy link
Contributor Author

@dearchap dearchap Oct 22, 2022

Choose a reason for hiding this comment

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

We need the test prefix check because otherwise when we run unit tests those flags get added !!!!

Also extFlag seemed better since we are not necessarily modifying any aspect of the underlying flag

Copy link
Member

Choose a reason for hiding this comment

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

@dearchap I'm in favor of filtering out `"test." in general 👍🏼 My thinking was more around if we could read this value from somewhere instead of having it hard-coded here 🤷🏼

As for extFlag, I meant that I wondered if you meant to use the struct and method receivers as structs rather than pointers to structs. In this implementation, there's going to be a lot more implicit copying of structs, IIUC.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@meatballhat do you want it to be defined as an App field or as a library var ?

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member

@Dokiys Dokiys Oct 26, 2022

Choose a reason for hiding this comment

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

@meatballhat do you want it to be defined as an App field or as a library var ?

@dearchap Maybe he means use pointer receivers(*extFlag) rather than value receivers(extFlag) implement Flag interface to avoid unnecessary data duplication.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No no that is fine. I meant the "test" prefix.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@meatballhat I updated the extFlag to be pointer receiver.

@dearchap dearchap merged commit ae8d932 into urfave:main Oct 28, 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.

Combine flags from other package
3 participants