Handle replace (old version to other version)

[DarthHater]

Thanks for creating an issue! Please fill out this form so we can be
sure to have all the information we need, and to minimize back and forth.

• What are you trying to do?
  In some upstream testing of hashbrowns, I noticed that in your go.mod when you:

replace github.com/gorilla/websocket => github.com/gorilla/websocket v1.4.2

go list -m all now shows:

github.com/gorilla/websocket v1.4.0 => github.com/gorilla/websocket v1.4.2

I have severe doubts that nancy handles this properly as of this moment, so you'd report on the old version, rather than the replaced one

• What feature or behavior is this required for?

Basically just keeping people up to date on what they are actually using!

• How could we solve this issue? (Not knowing is okay!)

Not entirely sure. There is a hacky way to do this, and then probably a less hacky way. One idea is to look at the structs, etc... that go mod itself uses, and see if we can leverage those for parsing the output similar to what we do with dep.

• Anything else?

Fun?!

cc @bhamail / @DarthHater

[zendern]

@DarthHater does go list with the Json option give us a more accurate picture?? If it does it still doesn't really give us backwards compibility since everyone had to change the command but maybe that's ok if we start to shift people away from that method ¯_(ツ)_/¯

Maybe that begs the question of maybe Nancy should auto detect what you do and do that stuff internally. Then we can switch to whatever is more accurate and no one has to modify anything. #spitballin

[DarthHater]

@zendern I'd love if Nancy could just do everything on it's own, but I have a few thoughts about that:

• Nancy doing everything on it's own ties it to Golang libraries for mod, which I don't think will change, but it's worth thinking about
• Right now you technically don't need golang installed to run nancy (you could cat a text file generated in a different environment), which is nice. I wonder if we start using go mod's libraries if we have to have golang installed as well?

However, I LOVE the idea of using go list -m -u -json all over the current way we have things, because it would be significantly easier to parse, AND it comes with some really nice info (like if there is an update to a current library, which we could use to query OSS Index to see if the update is good to go!). This is sorta tangential to this issue, but we can probably create one to support that path, and maybe get @MichelKazi / @TheCodinator19 to work on it!

[DarthHater]

Back to replace, it looks like the json output for it is something akin to:

{
        "Path": "github.com/gorilla/websocket",
        "Version": "v1.4.0",
        "Replace": {
                "Path": "github.com/gorilla/websocket",
                "Version": "v1.4.2",
                "Time": "2020-03-19T17:50:51Z",
                "GoMod": "/Users/ME/go/pkg/mod/cache/download/github.com/gorilla/websocket/@v/v1.4.2.mod"
        },
        "Update": {
                "Path": "github.com/gorilla/websocket",
                "Version": "v1.4.2",
                "Time": "2020-03-19T17:50:51Z"
        },
        "Indirect": true,
        "GoMod": "/Users/ME/go/pkg/mod/cache/download/github.com/gorilla/websocket/@v/v1.4.2.mod"
}

[zendern]

@zendern I'd love if Nancy could just do everything on it's own, but I have a few thoughts about that:

• Nancy doing everything on it's own ties it to Golang libraries for mod, which I don't think will change, but it's worth thinking about
• Right now you technically don't need golang installed to run nancy (you could cat a text file generated in a different environment), which is nice. I wonder if we start using go mod's libraries if we have to have golang installed as well?

So on the note of auto pilot Nancy....... maybe its an opt in feature. Something like nancy --autoscan and it'll do its best to determine which you are using go.mod/dep and then run the most accurate option we have to date. In the mod case go list -m -u -json all. Which probably means that turns into nancy "shelling out" to make that call since I believe we looked before and all the go mod code is internal and isn't supposed to be used by projects.

[DarthHater]

We could also try and talk with someone working on Golang and see if there is a potential of at least some stuff being moved from internal out?

The other reason to avoid just completely doing shell out to go list -m all is a few people who were using Nancy were actually running go list -m all on a bunch of projects and creating one text file to scan with. IIRC it was someone with a bunch of microservices?

[zendern]

👍 on the getting the conversation started on seeing if that is an option.

Re: txt file usage.... Yeah that's fine. I think if we did the auto run of go list it would be opt in via another flag so would still be possible to use a text file. Could be overkill to the more I think about it cause it not super hard to just pipe it in yourself but would alliveate the issues from here since we could control what is happening internally. (Or easily switch from no json to json and no one is the wiser)

On an unrelated-ish note, Might be worthwhile to detect at least the input type (json, text, dep, etc) and send that along the user agent so we know how it's being used exactly.