meatballhat
Repos
4
Followers
336
Following
398

A simple, fast, and fun package for building command line apps in Go

19366
1565

Idiomatic HTTP Middleware for Golang

7271
568

GitHub-Flavored Markdown Runner

34
8

Events

pull request opened
Consolidate all `App` code into `Command`

What type of PR is this?

(REQUIRED)

  • bug
  • cleanup
  • documentation
  • feature

What this PR does / why we need it:

(REQUIRED)

Which issue(s) this PR fixes:

(REQUIRED)

Fixes #1586 Fixes #1600

Special notes for your reviewer:

(fill-in or delete this section)

Testing

(fill-in or delete this section)

Release Notes

(REQUIRED)


Created at 21 hours ago
push

Dropping commented-out bits in app.go; leaving only type alias

Created at 21 hours ago
push

Starting to collapse App into Command

Connected to #1586 Connected to #1600

Created at 21 hours ago
create branch
meatballhat create branch app-command-collapse
Created at 22 hours ago
opened issue
Use `.Commands` field throughout (replace `.Subcommands`)
Created at 23 hours ago

Use valid event name

Created at 1 day ago

Add minimal github actions bits

Created at 1 day ago
pull request opened
Porting changes from urfave/cli integration attempt
Created at 1 day ago
create branch
meatballhat create branch cli-changes-fun
Created at 1 day ago
create branch
meatballhat create branch argh-core-attempt-zero
Created at 1 day ago
create branch
meatballhat create branch main
Created at 1 day ago
create tag
meatballhat create tag v0.1.0
Created at 1 day ago
create branch
meatballhat create branch urfave-cli-integration
Created at 1 day ago
create repository
meatballhat create repository
Created at 1 day ago
issue comment
Argh core

reopening shortly...

Created at 1 day ago
pull request closed
Argh core

What type of PR is this?

  • foundational
  • scary
  • experimental

What this PR does / why we need it:

Swap out stdlib flag with the "argh" parser

Which issue(s) this PR fixes:

Closes #1583

Special notes for your reviewer:

This is highly experimental ⚠️ I don't expect reviews at this time, which is why the PR is in draft 💖

Created at 1 day ago
push

Allow disabling SliceFlag separator altogether

replace test hardcode with defaultSliceFlagSeparator

godoc

Merge pull request #1582 from feedmeapples/allow-disabling-slice-separator

Allow disabling slice flag separator

Update godoc v3 spacing

Merge branch 'main' into v3-godoc

Merge pull request #1589 from feedmeapples/v3-godoc

Fix spacing in godoc

First cut at using generics for base flag types

Add generics

Stage

Rebase

Add all flags

Add FlagConfig

Rebase

Fix all tests

Remove debug log

Fix go1.18 crash

Run make v3approve

Fix doc tests

Changes from code review

Created at 1 day ago
issue comment
Minimize top-level API surface area for both usability clarity and maintenance reduction

@marwan-at-work can you move your comment over here? 🙇🏼

Created at 1 day ago
issue comment
Use a core flag parser other than stdlib `flag` to unlock wider range of arg types

@jtagcat do I understand correctly that you are recommending against integrating jtagcat/harg directly with this library, but instead to make a jtagcat/hcli project that uses it, and then use jtagcat/hcli in this library?

Created at 1 day ago
issue comment
Minimize top-level API surface area for both usability clarity and maintenance reduction

(Continuing discussion from #833)

context.Context is explicitly not meant to be extended

@meatballhat any documentation or links to where that explicit convention maybe written?

@marwan-at-work I should have explained myself better, sorry! The interpretation of the go docs I'm leaning on here comes from the overview

Do not store Contexts inside a struct type; instead, pass a Context explicitly to each function that needs it. The Context should be the first parameter, typically named ctx:

func DoSomething(ctx context.Context, arg Arg) error {
	// ... use ctx ...
}

meaning that we're not supposed to be wrapping context.Context with our own type because that goes against the convention of accepting context.Context as first argument for the purpose of keeping the semantics/expectations of using context.Context as simple as possible.

Aside from that particular interpretation issue, I'd like to make sure we are moving towards the design detailed in the series of issues tracked in #1531 which would result in an action func signature of:

type ActionFunc func(ctx context.Context, cmd *Command) error
Created at 1 day ago
issue comment
Release 3.x

context.Context is explicitly not meant to be extended

@meatballhat any documentation or links to where that explicit convention maybe written?

@marwan-at-work I should have explained myself better, sorry! The interpretation of the go docs I'm leaning on here comes from the overview

Do not store Contexts inside a struct type; instead, pass a Context explicitly to each function that needs it. The Context should be the first parameter, typically named ctx:

func DoSomething(ctx context.Context, arg Arg) error {
	// ... use ctx ...
}

meaning that we're not supposed to be wrapping context.Context with our own type because that goes against the convention of accepting context.Context as first argument for the purpose of keeping the semantics/expectations of using context.Context as simple as possible.

Aside from that particular interpretation issue, I'd like to make sure we are moving towards the design detailed in the series of issues tracked in #1531 which would result in an action func signature of:

type ActionFunc func(ctx context.Context, cmd *Command) error

I'd love to keep talking about this, and I also want to be sensitive to keeping discussions here very high-level, so I'm copying these comments over to #1531 for further discussion 🙇🏼

Created at 1 day ago
closed issue
Minimize top-level API surface area for both usability clarity and maintenance reduction
Created at 1 day ago
issue comment
Minimize top-level API surface area for both usability clarity and maintenance reduction

Duplicate of #1531

Created at 1 day ago
opened issue
Minimize top-level API surface area for both usability clarity and maintenance reduction
Created at 1 day ago
push

Remove flag type generation code

and related tooling, given all of it has been replaced by :sparkles: generics magic :sparkles:

Connected to #833

Merge pull request #1598 from urfave/rm-gen

Remove flag type generation code

Created at 1 day ago
delete branch
meatballhat delete branch rm-gen
Created at 1 day ago
pull request closed
Remove flag type generation code

What type of PR is this?

  • cleanup

What this PR does / why we need it:

Remove unused flag type generation code and related tooling, given all of it has been replaced by :sparkles: generics magic :sparkles:, to reduce potential confusion 🤞🏼

Which issue(s) this PR fixes:

Connected to #833

Created at 1 day ago
Created at 1 day ago
pull request opened
Remove flag type generation code

What type of PR is this?

  • cleanup

What this PR does / why we need it:

Remove unused flag type generation code and related tooling, given all of it has been replaced by :sparkles: generics magic :sparkles:, to reduce potential confusion 🤞🏼

Which issue(s) this PR fixes:

Connected to #833

Created at 1 day ago
create branch
meatballhat create branch rm-gen
Created at 1 day ago