auto-args for targets?

[natefinch]

It wouldn't be too hard to auto-generate a CLI for each target so the user could pass in positional args or flags per arg.

e.g.

func Build(OS string, ARCH string) error {
     // build with GOOS and GOARCH
}

$ mage build -os darwin -arch amd64
building with GOOS=darwin GOARCH=amd64

[natefinch]

May conflict with #34

[jrnt30]

While it's a little ugly, I think you could support both features if you kept the multi-target support to be explicitly delimited. The available bind targets then for the method arguments would be the union of the two. If both targets had an OS string in them, they would both be passed the same value.

[natefinch]

I see . what you mean, like if build had an OS string argument, and compile did too, but compile also had a output string then you'd call it like

mage build compile -OS=windows -output=foo.exe

That's not terrible :)

[vassudanagunta]

mage build compile -OS=windows -output=foo.exe

While it's a little ugly

That's not ugly, it's beautiful! And elegant if targets declare a same named arg and you only have to specify it once on the command line. Or where you thinking of some other approach, @jrnt30?

[jrnt30]

Now that was the general thought I had a well

[sean-]

I don't know about coupling the variables to the positional args for a given target. Wouldn't most use cases be satisfied with something closer to:

type Args map[string][]string

func Build(args Args) error {
  switch {
  case args.Get("GOOS") && args.Get("GOARCH"):
    // build with GOOS and GOARCH
  default:
    // other
  }
}

// Get returns the first argument
func (a Args) Get(key string) string { ... }

The interface is basically ripped off from https://golang.org/pkg/net/url/#Values.Get ? This solves a huge list of problems on our end with mage and would be a very, very welcome feature. Maybe return the args as part of a context.Context so we don't need to change the function signature for anything. ?

[natefinch]

I think the question is mainly how they're specified on the command line and how that interacts / interferes with calling multiple targets.

Getting args into the target itself is easy enough. Right now, you can do

GOOS=windows mage build
and then use os.Getenv("GOOS") to retrieve the value.

But defining the args in the target function's arguments is more elegant and lets us validate them automatically, produce docs for them, etc.

The only problem is how they look when you specify them on the command line, how or if we disambiguate between two targets' args, etc

[sean-]

That's true, too. I think if you have multiple targets, you have to scan from left to right and parse the args between the targets and use that as the rough function signature. Does order matter? That's problematic UX. How do you pre-register an argument so it's available as help? What if a target has 10 flags available and half of them are optional, then what? Pass them all in as arguments to the target func? Use a pointer to a string?

func Foo(barRequired string, bazOptional *string) error {

? but times however many args? The problem I have with using a container like a map[string][]string is how do you pre-register the args for a given flag so a --help dialogue can be populated (and provide the necessary description and/or code reuse across different targets)?