Wide refactoring

[psydvl]

• Separate mkappimage and appimagetool files
• Move some functions in separate packages or helpers
• Move GenerateAppImage function into goappimage package
• Some fixes
• Regenerate ExcludeLibraries
• Follow Standard Go Project Layout

[probonopd]

Hi @psydvl,
thanks for working on go-appimage.
I understand "Follow Standard Go Project Layout", but what else do you want to achieve? In other words, why do you think this should be refactored?

[psydvl]

Mostly written in commit messages, but general points:

• Symlinking appimagetool files in mkappimage is bad decision because of logic complexity
• os.Exit bad practice due two things:
  1. defer calls declined by it; can be solved by panic instead (will call all defer and raise exit code 2)
  2. "go way" is to raise errors from function to the highest level, keeping handle it as long as possible
• common function should be raised in separate simple packages when possible
• there are some recommendation to keep packages in cmd (other words cli utilities) slim as possible moving most function in other folders (that's why it is still draft)

Of course, I may be wrong about some changes and open to discuss any

Also, some fixes done due

• goimports auto formatting
• gofmt/gofumpt auto formatting
• default linters, from golangci-lint, recommendation

Steps I want to do in next commits:

• move cmd code to separate packages where its possible
• improve error handling (maybe with multierr or go-multierror)
• leave no warns on linters check

Inspired by:
https://go.dev/doc/effective_go
https://google.github.io/styleguide/go

[CalebQ42]

This looks great. I do have a couple things to mention.

• Should GenerateAppImage be in goappimage? goappimage is meant to interact with existing AppImages, whereas creating AppImages is the job of appimagetool/mkappimage. If someone were to create AppImages they should be using appimagetool not goappimage.
• Why create a Makefile? Ultimately it's just calling the build script anyway so seems completely superfluous.
• This is very tiny, but irritates me for some reason: There is very few times where you need to "properly" handle the error returned by .close(). In particular you "properly" handled an os.File which will only return an error if the file has already been closed. If an error from close matters then it really shouldn't be defered. Again not something that actually matters, just something that irritates me unreasonably.

[probonopd]

Yes, let's not introduce the need for a makefile.