Vendor Obsolete

[kendfss]

I clone the repo then run: cd license; go mod tidy; go build

which gives following error:

go: inconsistent vendoring in /Users/kendfss/gitclone/clones/nishanths/license:
    github.com/onsi/gomega@v1.16.0: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt

    To ignore the vendor directory, use -mod=readonly or -mod=mod.
    To sync the vendor directory, run:
        go mod vendor

And when I ignore (i just removed the vendor directory), it built and works normally. I think since the readme recommends go install and any version of go that supports install supports modules, the vendor directory isn't useful anymore.

[ghost]

I've opened a PR to remove the directory, see #35.

[nishanths]

I created a v5.0.1 tag just now, which should include this change.

[5cat]

Regarding the vendor directory. I'm currently trying to package the application for gentoo, having the vendor folder would really help as stated in here are there any plans to bring it back?

Otherwise I would need to host the vendor files somewhere for each version of the application which can get messy. What do you think?

[nishanths]

@5cat: Yes, we can do this. Couple of notes and questions:

• We likely won't add the vendor directory back on the master branch. Instead, does having a "mirror" branch named master.vendor work for you? The branch would have identical source, except that it would use a vendor directory for the dependencies.

• How should tagging work, so that it makes maintenance easier for you/Gentoo? If we tag, say, v9.1.2 in master, what should the equivalent tagging look like in the vendored branch? I was thinking something like v9.1.2-vendor, but I'm leaning against this particular format because Go considers hyphenated suffixes after the version number to indicate pre-releases (some other tag format could be acceptable though).

  Alternatively, would it be okay for you if there were no tags at all for the vendored branch?

[5cat]

• Live ebuilds: I think you dont need to create the master.vendor at all, I just noticed go-module_live_vendor so I did a live ebuild of master and called it a day : ).

• Versioned ebuilds: As for the tagging I agree with you, using pre-releases part for the vendor is not optimal because it will make it harder for the project when there are actual pre-release such as alpha/beta etc. we can do vendor-v9.2.1 so they dont become part of the version and when users browse the tags in github it will be sorted alphabetically it will not be full of vendor tags, vendor tags will be displayed at the bottom of the list. Another option is instead of the tags we can use github releases feature and include the vendors as an asset or the full source code with vendors as an asset.

For now I'm happy with the live ebuild solution since all I wanted is to use this wonderful tool. But If the tags/release solution is implemented I would of course create ebuilds for those, live versions are not that stable.