search

laktak / zfind

search for files (even inside tar/zip/7z/rar) using a SQL-WHERE filter
MIT License
357 stars 5 forks source link

Using `go install` and versioning #3

Open Daeraxa opened 4 weeks ago

Daeraxa commented 4 weeks ago

I was going to submit a PR to see if you were interested in adding a line to the installation section of the readme for installing via go install - e.g. go install github.com/laktak/zfind/cmd/zfind@latest. However if this is done the output of zfind --version returned vDev as this is what is actually in the source code (as it seems that on normal binary releases you are changing this via CI?).

This does however mean that downloading the source code of a tagged release also has this vDev rather than the actual version of the tag. Would it makes sense to actually update the version in the tagged release? i.e. this link (https://github.com/laktak/zfind/blob/v0.4.1/cmd/zfind/main.go#L14) is to the v0.4.1 tagged release and still shows it versioned as vDev rather than v0.4.1.

laktak commented 3 weeks ago

Yes, the version is inserted by the CI.

I've added a build script to insert the correct version:

https://github.com/laktak/zfind/blob/master/scripts/build

But that only works if you clone the repo. I think vDev when installing via go install is OK.

Daeraxa commented 3 weeks ago

I think vDev when installing via go install is OK.

If you install with the @master version query then yeah but shouldn't it be the correct version listed if you installed a tagged release? Essentially using go itself as a package manager for installing zfind rather than brew or manually grabbing binaries.

laktak commented 3 weeks ago

Yes, I'd like that as well but I don't want to commit version numbers to git. I think tags are a far better solution.

I couldn't find any predefined "version" variables, so this is not as nice

go install -ldflags="-X main.appVersion=v0.4.2" github.com/laktak/zfind/cmd/zfind@v0.4.2

but it does work.

Daeraxa commented 3 weeks ago

I agree tags are a good solution but you do techically still end up in a weird situation here where your distributed source code as part of your tagged release isn't actually the same as is in the binaries.

The main issue with the above go install... is obviously that it requires knowing the released version where @latest makes that process much easier.

I have to admit I don't know what the best solution actually is, I know for our releases we create a tag and edit the version then post-release we create a new commit that re-adds the "-dev" version to the master branch. Not exactly the neatest solution and not automated either.

Apologies if I'm overcomplicating things, feel free to mark as "won't fix" and I'll not bother you any more, not here to be beligerant or entitled about things. I've not messed around with Go all that much so that ability to pass the version via -ldflags is already new to me. Either way I'm interested to learn more so I'll happily go away and see if there is a neater way to see if people do this kind of thing and would be up for submitting a PR if I learn anything (if you are open to such a thing).

laktak commented 3 weeks ago

Hey, no problem :)

I checked two of my favorite tools (lf and fzf), which are also written in go, how they handle this and they both use the same strategy and both have the same issue.

In any case, if you discover a solution please let us know! For now I'll just add go install (without a version) to the README.