Externalize bindata.go to an auto-generated file about gitea

[strk]

I generally agree on never keeping anything that's not source code into the repository.
What I've understood is that bindata.go is there to allow for "go get" to get you a compiled binary, so basically a workaround to a "go get" limitation. But I don't have further references about this limitation and other possible workarounds.

In all cases, I think it is acceptable to go get ...; less README.md; make;

[tboerger]

I don't agree on that. There are no other ways to stay go gettable than adding bindata to the repo.

If there are other ways around we can talk about that.

[tboerger]

BTW, go get will fail without the bindata because the imports can't be accomplished

[strk]

@tboerger it will fail but will have downloaded all the sources, right ?

[tboerger]

But if I go get something I expect to have it working without reading the readme to find out what else needs to be done

[strk]

I'm not a long Go user enough to know what one would have to expect by "go get". I've read it's not a package manager, but I do see it being used as such

[strk]

For the PR mess (conflicts and changelogs size), I shall note that @unkwon used to only update bindata.go before releases, and not accepting those updates in the PRs themselves.

[tboerger]

I would suggest an additional commit made by the CI system that updates the bindata.

[strk]

If bindata.go has to stay, +1 for the CI system automation (only if it would change).
But I'd really prefer to give-up go-get'ability than keeping generated files in the repo.
How about making bindata.go usage optional, so to retain go-getability while still allowing bindata.go usage upon request ?

[strk]

@tboerger is the optional bindata.go what you'd get with build tags ? (#74 (comment))

[strk]

My take on the optional embedding of files is in this PR: #78
I've understood @tboerger is also working on making embedding optional in his #74, but I think that PR also adds public and templates into the bindata, so maybe it make sense to divide the work in two steps, for easier reviews ?

[strk]

For reference, @tboerger PR about conditional bindata embedding is #30 (came out in gitter chat)

[strk]

So, should this be closed as a duplicate of #30 ?

[tboerger]

Duplicate of #30