Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fyne should have a "version" command #656

Closed
xxxserxxx opened this issue Feb 6, 2020 · 9 comments
Closed

fyne should have a "version" command #656

xxxserxxx opened this issue Feb 6, 2020 · 9 comments
Labels
enhancement New feature or request

Comments

@xxxserxxx
Copy link

The bug report template asks for the fyne version, but there's no way to do it except to go to the git checkout and query git.

If there's a way to get the version, it'd be great if that could be documented in the bug template, because it's not obvious.

$ fyne version          
Unsupported command version                                                                     
$ fyne --version                                                                                
Usage: fyne [command] [parameters], where command is one of:                       
  install, bundle, get, package or help                                                         
... (trimmed help text)
$ fyne -v
Usage: fyne [command] [parameters], where command is one of:
  bundle, get, package, install or help
... (trimmed help text)
$ fyne -version
Usage: fyne [command] [parameters], where command is one of:
  package, install, bundle, get or help
... (trimmed help text)
@andydotxyz
Copy link
Member

Agreed. With modules it is easier, but this would be a helpful addition

@andydotxyz andydotxyz added the enhancement New feature or request label Feb 6, 2020
@Cherrg
Copy link

Cherrg commented Feb 9, 2020

I think the bug template asks for used version of fyne.io/fyne used to compile a current app, so i think the 'git status' or 'git log', or something like that should be the correct choice.

  • build fyne.io/fyne/cmd/fyne for the 'fyne' command
  • change the branch/checkout for fyne.io/fyne, which is used to compile other apps (i think so)
  • compile something, and may report a bug
    --> there could be a mismatch between compiled version of fyne and the one used to build other applications...
    --> if an application uses some kind of vendor directory and manages packages, there could be a different version of 'fyne', fyne.io/fyne inside the normal go path and the one used to produce the bug

@xxxserxxx
Copy link
Author

Yes, that's what I'm doing currently; and it isn't a problem. However, because many (most?) people use go get to install Go software, they're not directly checking out the project with git -- your step 2 is really only going to be common for people developing on Fyne, not the people using it.

There isn't a good answer. Subversion had a nice ability to embed revision numbers in files, which both git and mercurial lack, and because the design of go get explicitly forbids arbitrary code execution it can't be done with (e.g.) a go:generate command. So, digging around and finding where go checked out the code using go get (easy enough for seasoned users of Go, but maybe harder for casual users) is really the only option that I can think of.

That said, thanks to modules we can get some information about fyne, and I think it'd be useful if it can be collected. For example:

➜ strings `which fyne` | grep pkg/mod | grep -oP 'pkg/mod/\K.*@v?[0-9.a-f-]*' | sort | uniq
github.com/akavel/rsrc@v0.8.0
github.com/jackmordaunt/icns@v0.0.0-20181231085925-4f16af745526
github.com/josephspurrier/goversioninfo@v0.0.0-20190124120936-8611f5a5ff3f
github.com/!kodeworks/golang-image-ico@v0.0.0-20141118225523-73f0f4cfade9
github.com/nfnt/resize@v0.0.0-20180221191011-83c6a9932646
github.com/pkg/errors@v0.8.1

Although, I just tried this on another machine and the module information isn't in that binary :-/
It doesn't tell us which version fyne itself was at, but it does tell us what it was built with.

@andydotxyz
Copy link
Member

Hmm that is an interesting point. There is no guarantee that ‘fyne version’ would report the version that an application was built with. I’m not sure about the right way to do this now. There is some value in “fyne version” but probably only when reporting issues with compiling or packaging...

@Cherrg
Copy link

Cherrg commented Feb 9, 2020

may do two steps:

  • add to cmd/fyne like suggested
  • add some additional comment to the bug report template

@xxxserxxx
Copy link
Author

Or, maybe we're making this too complex. Modules is now official and recommended in 1.14, so maybe the instructions should be to include go.mod in addition to the fall-back of looking for the version of the fyne library being used.

I still suspect that, using the go internal API, the fyne executable should be able to figure out the version of the fyne library that it's using to compile and package an application with. With -executable, all bets are off, I agree. However, a library-version command for the fyne executable would be useful for bug reporting -- assuming that the tooling fyne package uses does leverage modules.

@jkvatne
Copy link

jkvatne commented Feb 11, 2020

Try issuing the commands:

cd $GOPATH/fyne.io/fyne
git describe --abbrev=8 --dirty --always --tags 

To embed it in a program, you can use

cd $GOPATH/fyne.io/fyne
printf  "package main\n\tconst FyneVersion=\"" > ~/my/src/version.go
git describe --abbrev=8 --dirty --always --tags  | tr -s '\n' '"\n' >>  ~/my/src/version.go

This wil generate a version.go file with the constant string FyneVersion set to the used fyne version.
I have added a similar command to mey GoLand editor that is executed by the build process, so I allways embed the used version from my repository.

(Note that the given git describe command is very flexible, and will normaly print the latest tag, but adds the hash if the latest commit is not taged. And it adds -dirty if the code has been modified.)

@xxxserxxx
Copy link
Author

@jkvatne -- this admirably solves the question: which version of the fyne binary command are you using? Another, possibly more important, question is: which version of the fyne library are you compiling your application against?. These are not guaranteed to be the some, and indeed, I will predict that in several months, it will more often than not be true that they're different versions. Go modules almost guarantees it.

When reporting bugs against the fyne tool, the first is important. When reporting bugs against the library, the second is. I think we need both.

@andydotxyz
Copy link
Member

I believe this has been resolved in @lucor's recent changes. fee681e

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants