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

Refactor command functions #859

Merged
merged 1 commit into from
Jun 11, 2019
Merged

Conversation

errordeveloper
Copy link
Contributor

@errordeveloper errordeveloper commented Jun 7, 2019

Description

Checklist

  • Code compiles correctly (i.e make build)
  • Added tests that cover your change (if possible)
  • All unit tests passing (i.e. make test)
  • All integration tests passing (i.e. make integration-test)

@errordeveloper errordeveloper requested a review from martina-if June 7, 2019 15:49
@errordeveloper errordeveloper force-pushed the refactor-command-functions branch 2 times, most recently from e1f6e02 to a82c616 Compare June 7, 2019 16:07
@errordeveloper errordeveloper marked this pull request as ready for review June 10, 2019 07:32
pkg/ctl/cmdutils/resource.go Outdated Show resolved Hide resolved
pkg/ctl/cmdutils/resource.go Outdated Show resolved Hide resolved
cfg := api.NewClusterConfig()
ng := cfg.NewNodeGroup()
rc.ClusterConfig = cfg
Copy link
Contributor

Choose a reason for hiding this comment

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

Since there is no other command in this context can we rename rc to cmd or command which is easier to understand what is is?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's ResourceCmd, hence rc. Using resourceCmd would be too verbose IMO. Calling it resource is also kind of misleading, it's not really a resource. Maybe we could rename the struct? But I've already tried a bunch of names, and this is the only one that sticks... Anyhow, to me this PR is only start of the process, I'd rather go on to next thing and revisit this later.

We will soon need to get more refactoring done and decouple things into a library that doesn't have any assumptions about being a used in CLI, so we will have revisit this. I suspect we might turn ResourceCmd into an interface that will have CLI-oriented implementation, and a more general one also. But it's a little too early to decide on that.

Copy link
Contributor

Choose a reason for hiding this comment

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

Why not just command or cmd? it is a resourceCmd but there could be a similar actionCmd or similar and they would all be commands. What do you think?

@@ -14,45 +11,40 @@ import (
"github.com/weaveworks/eksctl/pkg/eks"
)

func createIAMIdentityMappingCmd(g *cmdutils.Grouping) *cobra.Command {
p := &api.ProviderConfig{}
func createIAMIdentityMappingCmd(rc *cmdutils.ResourceCmd) {
Copy link
Contributor

Choose a reason for hiding this comment

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

If all these create*Cmd() functions manipulate the first parameter, ResourceCmd, I think it would be more idiomatic if it was the receiver of these methods. Since I don't normally expect a parameter of a function to be mutated by it. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it would be more idiomatic if it was the receiver of these methods

yes, but that means all those have to be in the same package...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Since I don't normally expect a parameter of a function to be mutated by it.

It's unfortunate, but we already have too many places where *api.ClusterConfig is passed in and mutated, which is kind of by design. We can discuss how that can be fix, but I'm not entirely sure if it the most important thing at the moment. (Only if there was a way in Go to prevent mutation!)


group.InFlagSet("General", func(fs *pflag.FlagSet) {
rc.AddCommand(func() error {
return doCreateIAMIdentityMapping(rc, id)
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure about this cyclic dependency here: rc -> doCreateIAMIdentityMapping -> rc. I need to think about this

@@ -82,11 +68,11 @@ func doDescribeStacksCmd(p *api.ProviderConfig, cfg *api.ClusterConfig, nameArg
}

for _, s := range stacks {
if !describeStacksAll && *s.StackStatus == cloudformation.StackStatusDeleteComplete {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the old names here were more clear, I would leave them as they were.

@martina-if
Copy link
Contributor

Nice refactor! And I think it's great that we also rename other things like p to provider. I would rename the rc to something else that's more clear. Maybe something like cmd, command, action, context or something like that, because today, there are a lot of things with very short cryptic names like ctl, fs and it would be nice, specially if we get more contributors, to make the code more explicit and easy to read.

- create short-hand methods for defining standard commands
- move most of common parameters to a struct
- get rid of global state
- improve overall consistency of command functions
@errordeveloper errordeveloper force-pushed the refactor-command-functions branch from a82c616 to dbedfd1 Compare June 10, 2019 16:15
@errordeveloper
Copy link
Contributor Author

errordeveloper commented Jun 10, 2019

I've renamed a few more things, name got rid of g (it's flagGrouping now). Let's leave rc as is for now, and revisit later. I agree it could have a better name, but I've been overthinking it for too long already tbh, I think it's the name of struct, but as I said we need should try to think of librarisation next, and I'm sure something better will come up in the process!

Copy link
Contributor

@martina-if martina-if left a comment

Choose a reason for hiding this comment

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

If you say we will get rid of the rc in the next PRs we can merge this

@errordeveloper
Copy link
Contributor Author

@martina-if yeah, next PR towards #813.

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.

add common structs for command options
2 participants