cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)

[skillful-alex]

Here is the fix for this issue! => #925 (comment)

edited by @lynncyrin!

---

After the last 2 months there was an error:
cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
In commit ebc2565 error not exists.
In corrent master error exists.

[AudriusButkevicius]

I don't think this has enough details to understand the problem.
Do you have a reproduction example, of code that worked and now doesn't?
What go version are you using,? Are you using go modules? Which version of the library you are using?

[ffrank]

Stumbled upon that as well. We have code as follows

                runFlags := []cli.Flag{
                        cli.BoolFlag{
                                Name:  flagDownload,
                                Usage: "download any missing imports (as the get command does)",
                        },
                        cli.BoolFlag{
                                Name:  "update",
                                Usage: "update all dependencies to the latest versions",
                        },
                }

It produces this error message:

lang/gapi.go:79:16: cannot use cli.BoolFlag literal (type cli.BoolFlag) as type cli.Flag in array or slice literal:

	cli.BoolFlag does not implement cli.Flag (Apply method has pointer receiver)

HTH!

[AudriusButkevicius]

Let me guess, you are not using go modules or any form of vendoring and pull stuff straight from master and build against that?

[ffrank]

You know, I had this same question 😅 and our main author has it covered:

https://github.com/purpleidea/mgmt/blob/master/docs/faq.md#why-arent-you-using-glide-godep-or-go-mod-for-dependency-management

I have since been informed that we'll probably need to update this code to match the API change. (On it.)

[AudriusButkevicius]

Well this was an intended change to a new version of the API, so I guess you just have to fix your side of things.

We expect potentially one more of these breaking changes next year.

[skillful-alex]

ok, but change manual.md , line 547:

package main

import (
  "log"
  "os"

  "github.com/urfave/cli"
)

func main() {
  app := cli.NewApp()

  app.Flags = []cli.Flag {
    cli.StringFlag{
      Name: "password, p",
      Usage: "password for the mysql database",
      FilePath: "/etc/mysql/password",
    },
  }

[saschagrunert]

@skillful-alex please refer to the v2 manual for the latest documentation.

[godd9170]

For any Go noobs out there like me, here's how I repaired my app:

1. Remove any instances of required packages from your $GO_PATH/src/
2. run go mod init github.com/<OWNER>/<REPO> in the root of your app.
3. run your package go run .

This will generate a go.mod file pre-populated with any requirements found in imports

4. update anywhere that uses go get -d -v (Such a as Dockerfile) to use go mod download

You can see my commit here: Guestlogix/pat@02d0481

[coilysiren]

Oh no! I'm so sorry everyone, we had no idea people were using the package from the master branch.

As described above, you'll want to do either of the following things:

1. change your code to use go modules so you can pin v1, or
2. update the flag interface for the v2 api changes

There's a few things we can do in this repo:

1. create the v1 => v2 migration guide Create a v1 => v2 migration guide #921
2. update the documentation to mention the v2 manual
3. make it clear that v2 is being used by default
4. follow-up with everyone who had this problem to see if they are still broken

[coilysiren]

@hussamd, @jangaraj, @maxcnunes, @sybnex, @nathancoleman-wf, @max0ne, @juansc if you are still having this issue, can you let me know where you're experiencing it? I'm trying to chase down all of the projects that need to be fixed.

[coilysiren]

2nd try ~! @hussamd, @jangaraj, @maxcnunes, @sybnex, @nathancoleman-wf, @max0ne, @juansc if any of you are still experiencing issues, please followup with me!

[nathancoleman-wf]

@lynncyrin My team pinned this repo to the last working version a while ago

[coilysiren]

Thank for that information!

It looks like everyone's issue here was that they were using this library straight from master, which causes obvious issues whenever we need to release a new major version. The fix here is to do either of the following things:

• migrate from v1 to v2, as described here Create a v1 => v2 migration guide #921
• pin a v1 version, as described here Create a short guide on how to pin urfave/cli v1 #928

I'm going to copy paste this a few times on related issues, so that everyone is aware of the solution here.

[juansc]

@lynncyrin thanks for the follow up. We also pinned the repo but we'll look at the steps to migrate from v1 to v2.

[coilysiren]

I've been compiling migration instructions here => https://github.com/urfave/cli/releases/tag/v2.0.0 ^^