no version number "go install" procedure

[FedericoMuciaccia]

Describe the bug
latest LazyGit version is v0.41.0 but this number doesn't show with lazygit --version if the (latest) package is installed by go install.
this also wrongly triggers the internal update manager.

To Reproduce

# install lazygit via "go install"
go install github.com/jesseduffield/lazygit@latest
# check the installed version
lazygit --version

the output is:
commit=, build date=, build source=unknown, version=unversioned, os=linux, arch=amd64, git version=2.34.1
which has no information about the version number

Expected behavior
version=0.41.0 in the output of the above commands

[stefanhaller]

I don't think I'd consider this a bug. To include the version number in the build, you have to tell go to do that by doing something like go build -ldflags="-X 'main.version=0.41.0'". Without that, there's no way for go to know that it is supposed to do this.

[FedericoMuciaccia]

manually specifying the version number is very inconvenient and error-prone (expecially regarding automatic updates)...

other programs installed in the exact same way do it automatically (so I guess there is also a way for LazyGit to do it automatically and without user intervention).
for example, by installing fzf (a famous fuzzy finder)

go install github.com/junegunn/fzf@latest
fzf --version

you get its correct version number:

0.51 (devel)

[FedericoMuciaccia]

I am no expert in Go, so sadly I have completely no idea about suggestions on how it can be done :(

[stefanhaller]

fzf does it by hard-coding the version number in the source code. We don't want to do this for several reasons.

Also, it's quite a deliberate decision that packaged builds have a version number, but manual builds do not. For example, packaged builds will show a "breaking changes" message when you upgrade from one version to the next; manual builds don't, because you might be in between versions, so it wouldn't be clear when to show the message.

My take on this is that if you insist to install lazygit manually, you get what you asked for; if you want to have a version number, install an official, packaged build.

What package manager are you using, and is there a reason why you don't use the lazygit package that it provides?

[FedericoMuciaccia]

I compile it from source because I don't have root/sudoer permission on the server I'm working on: I cannot use the regular package manager.
So I install Go with GoUp and then LazyGit with go install.
I do the same with Rust packages, using cargo install: my entire userland is compiled from source in my home directory. This give me a lot of freedom from the decisions of the system administrator of the server I'm working on.

Reading your answer, I think I can be misinterpreting one point:
Do go install github.com/jesseduffield/lazygit@latest install the latest tag/release (as I was thinking) or the latest commit (as in cargo install --git ...) ?
In case 2 (as it seems from your answer) I can see that assigning a release number could be (will surely be) misleading: in that scenario, I would go with the Rust/Cargo solution: assigning the commit hash as the release version string.

I think that assigning some sort of unique number/identifier to manual builds is very useful. For example, if I install LazyGit from source and my build has no version number, how can my bug reports be any useful to the developers? The entire setup will not be reproducible...

Anyway, thank you for this very useful piece of software.
Once discovered, I cannot work without it anymore :)

[stefanhaller]

Reading your answer, I think I can be misinterpreting one point: Do go install github.com/jesseduffield/lazygit@latest install the latest tag/release (as I was thinking) or the latest commit (as in cargo install --git ...) ?

It installs the last tagged release, but using @master instead of @latest installs the head commit of the master branch. And that's what I meant: if we were to hard-code the version number in the source code, like fzf does, then there would be no way to tell the difference between the two.

[stefanhaller]

my entire userland is compiled from source in my home directory.

I think that assigning some sort of unique number/identifier to manual builds is very useful. For example, if I install LazyGit from source and my build has no version number, how can my bug reports be any useful to the developers?

I see. In that case, I recommend to clone the lazygit repo, cd into it, and type go install there. This will give you a lazygit binary that reports the commit hash it was built from. (Lazygit contains some bespoke code to support this scenario.)

As far as I can tell, there is no way for us to achieve the same thing when you use go install github.com/jesseduffield/lazygit@xyz.

[PeterCardenas]

would we be open to checking which tag resolves to the commit hash and use that instead for the version?

[stefanhaller]

would we be open to checking which tag resolves to the commit hash and use that instead for the version?

I don't see how. The commit hash that we are using is baked into the binary by go during the build process; we don't have the tag available there.

[PeterCardenas]

oh i was imagining making a github api call

[stefanhaller]

On every startup? No, I don't think that's worth it.

[PeterCardenas]

it could be cached and async but i admit pretty hacky