The gup command has been used by more people than expected. However, the implementation and design of the gup command have a very low level of completion for the following three reasons:

1. It was implemented by developers who were unfamiliar with golang at the time.
2. There was a major forced change from the initial design.
3. Functionality was added without limitations.

Due to these reasons, the gup command has become difficult to maintain, especially in terms of writing test code.Therefore, a complete refactoring will be performed before upgrading to version 1.0.0.

Reddit post
Cool little command there. I typically like to be deliberate and explicit when I update something, but I do loooove updating software, so I'm sure it's nice to have something like this if you don't mind doing it all at once.

Minor thoughts:

• The config file won't work on Windows unless someone set a HOME env var (which happens). I use Ubuntu at home and Mac at work, but I Sometimes you can depend upon things like UserProfile, but Plan9 is lowercase, I believe. It's often safest to use UserHomeDir().

• I also noticed you abort if you run into a binary that doesn't have module info. You might have that problem if you built a binary before modules were introduced unless it gives you some sort of sentinel value. I'm not actually sure on the output in that case... either way, it might be good to warn and keep building the list of binaries to update.

• Cobra seems like a pretty big dependency tree to pull in for a command that has no options or other complexity to it. Some people like it, but I don't, so I would remove it. That is of course just my personal preference, and not about good or bad.

• line 70 in https://github.com/nao1215/gup/blob/main/internal/goutil/goutil.go you probably want to say "a directory" instead of "the directory".

I hope you don't mind the thoughts. I know you didn't ask for feedback, and none of it is very important, but I am procrastinating on some work I need to do...

Questions:

• Will this work if someone does go install from a random project somewhere on their computer instead of feeding the command a URL? I know the main package isn't moved to the module cache, but what I'm not sure of offhand is what the path looks like in the version command in that case.

• If you have never run go install, there is no bin folder yet, so

• You concatenate $GOPATH and /bin. Do you think forcing that if there is a $GOBIN set is the correct choice?

See #6

ran gup update
and got fatal: not a git repository (or any of the parent directories): .git

As shown below, the command go-carpet falls back from v1.9.1 --> v1.9.0.

$ gup update
** snip **
gup:INFO : [18/25] github.com/msoap/go-carpet (v1.9.1-0.20220908165354-f7355b5d2afa to v1.9.0)
** snip **

Perhaps this is due to the way the version is defined during go install.

Since I wanted the "patched-latest-master" to be installed rather than the released version, I go installed with the version tag as a branch name. Such as:

go install "github.com/msoap/go-carpet@master"

The released version of this go-carpet command is v1.9.0. Though, as of Go v1.18 the buildinfo detects the version from the commit, it automatically increments the patch version. In this case from v1.9.0 to v1.9.1-0.20220908165354-f7355b5d2afa.

But, the gup update will fall back if the version doesn't match to the latest.

To Reproduce

$ gup check go-carpet
gup:WARN : not found 'go-carpet' package in $GOPATH/bin or $GOBIN
gup:FATAL: unable to check package: no package information

$ go install "github.com/msoap/go-carpet@master"

$ gup check go-carpet
gup:INFO : check binary under $GOPATH/bin or $GOBIN
gup:INFO : [1/1] github.com/msoap/go-carpet (current: v1.9.1-0.20220908165354-f7355b5d2afa, latest: v1.9.0)

gup:INFO : If you want to update binaries, run the following command.
           $ gup update go-carpet

$ gup update
** snip **
gup:INFO : [23/25] github.com/msoap/go-carpet (v1.9.1-0.20220908165354-f7355b5d2afa to v1.9.0)
** snip **

Expected behavior

If the current version is greater than the latest, then do not fall back. Or at least ask the user to fall back.

Env info

• OS: macOS Monterey (OSX 12.5)
• gup: v0.10.5
• go: v1.19.1 (Darwin/amd64)

What

I'd like to have a flag to disable notifications. I don't need them and it warns everytime with gup:WARN : exec: "notify-send": executable file not found in $PATH.

How

I'm thinking of something like gup update --no-notification (I'm fine with any other flag).

Checklist

• Finish implementation of the issue
• Test all functions
• Have enough logs to trace activities
• Notify developers of necessary actions

I would like to use go install -ldflags='-w -s' pkgurl@ver for everything, this reduces binary sizes in GOBIN by ~ 30% (overall).

Is there a way to set those when using gup? Like when gup update pkg, then gup should use those ldflags?

LDFLAGS="-w -s" go install -v github.com/jesseduffield/lazygit@latest
GO_LDFLAGS="-w -s" go install -v github.com/jesseduffield/lazygit@latest
CGO_LDFLAGS="-w -s" go install -v github.com/jesseduffield/lazygit@latest

$ file ~/go/bin/lazygit
/data/data/com.termux/files/home/go/bin/lazygit: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker64, Go BuildID=LLfEyEXjEMrHvyjZonKj/4Fhy_N4CI4C1iqkyYndi/Bccr-D0Pj5lrRwMW3oUo/YAQMGE7PR-yDhkUxbTdR, with debug_info, not stripped

$ file ~/go/bin/lazygit
/data/data/com.termux/files/home/go/bin/lazygit: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker64, Go BuildID=CRHRVUhGdkG5b7WqnThF/qtUCSK8Z1bQhyb1zl3GH/Bccr-D0Pj5lrRwMW3oUo/lbWf2uesZwgNtp_3y9lt, stripped

What

--dry-run is slow because it always performs the build process in a temporary directory.
Updates without dry run require fewer builds. This case is so fast.

How

under consideration

Nice tool - thank you.

Here are some suggestions for improvements you may not have thought of. It is intended as helpful comments, not criticism, so feel free to implement, adapt or ignore as you choose :-)

Help

gup --help needs more text - this could do with some of the text in the README.md. I wasn't sure how to use the command just by looking at this help.

$ gup --help
Update binaries installed by 'go install'

Usage:
  gup [flags]
  gup [command]

Available Commands:
  completion  Generate the autocompletion script for the specified shell
  help        Help about any command
  import      Install command according to gup.conf
  version     Show version information

Flags:
  -h, --help   help for gup

Use "gup [command] --help" for more information about a command.

Dry run mode

With tools that are making changes to my system, I'd really like a --dry-run mode so I can see what the tool would do if I ran it.

Update named items only

I'd like the tool to be able to update only the binary (or binaries) I mention in the command line, not everything.

Update needs a flag or command

It probably shouldn't update everything unless you pass a flag - say -a or --all, or maybe with a subcommand gup update. I can tell you that sysadmins get upset with commands that do loads of stuff when you run them with no arguments. How do I know this? Well, I write tools for sysadmins and got a lot of very direct feedback!

List

A list subcommand which lists current versions of everything would be nice.

I really like the idea to promote the use of shell completions and enhance the user experience. but please make it a bit more configurable.

I am using ~/.bash_completions.d/gup.conf in preference over a massive ~/.bash_completion file.

Could we either have a switch for the generation of the completions or have the location be configurable?

The gup command generates shell completion files for bash, zsh, and fish.
However, gup does not generate shell completion file for PowerShell.

I do not have Windows, so this task has a very low priority.
I would be happy to have this feature implemented for Windows users!!
There is a function (GenPowerShellCompletionFile()) that generates a shell completion file for PowerShell, so it can be implemented if you know where to generate the file.

About the problem

Packages installed via "go install <importPath>@master" or "go install <importPath>@main" gets replaced into "<importPath>@latest" after gup update.

It seems similar to #36 but a little different. Since the down-grading issue has been fixed.

• Related issue:
  • #36

Steps to reproduce

$ # Install the latest master (not the latest release)
$ go install github.com/msoap/go-carpet@master
** snip **

$ go-carpet -version
1.9.0

$ # -mincov option exists
$ go-carpet -h 2>&1 | grep mincov
  -mincov float

$ gup update
** snip **

$ go-carpet -version
1.9.0

$ # -mincov option does not exist
$ go-carpet -h 2>&1 | grep mincov
$

Note

This behavior does not happen if the packages are never version-tagged. Because in that case the versions are v0.0.0-<commit id>.

This occurs when the package owner has not published/released the changes made to the current master or main branch.

Expected behavior

If the installed packages are tagged such as @master or @main then gup update should install the latest source and not the latest release.

Possible causes

1. Even if the previous and next versions are the same, gup update will install the "latest" packages.

Possible fixes

This is a difficult task. The reason is that it depends on how the term "update" is treated.

My current proposes are:

1. Compare the versions and skip the update function if they are the same. (-f, --force flag for the original behavior)
   • PROS: Simple
   • CONS: Gets slow (due to the GetLatestVer call) and @master installed app never gets updated unless re-installing manually.
2. Obtain the version tag from the pulled repo and use it if they are not @v??.??.?? or @latest (e.g. @master or @main), otherwise use @latest.
   • PROS: It will follow the initial go install <package>@<branch> installation.
   • CONS: Don't know how to obtain the version tag ...

Current workaround

• Reinstall manually via go install <package>@<branch> until the package owner comes back from his/her vacation.

Env info

• OS: macOS 12.6.1 (OSX Monterey) and Alpine Linux v3.16 (via Docker, golang:alpine image)
• Go Version: 1.19.3 (Both macOS and Linux)
• Application Version: gup v0.15.1

When installing golangci-lint it is recommended to not install it via go install but instead update it manually.
So it would be nice if I could run something along the lines like:

gup update --ignore golangci-lint
Or even have a seperate config file.

If I run gup update bin1 bin2 … (basically all installed binaries except golangci-lint) I face the downside that when I create an alias and later add another binary, that I then have to update this alias.

Currently I just run
curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(go env GOPATH)/bin v1.52.2
after gup update

Gup updates all packages at once which when there are many (eg ~70 in my case) takes up all the ram 8GB and all cores are at 100% at 89°C. As it spawns ~1900 threads. Thus it is unusable and I had to force quit linux.

Maybe limit it to the number of cores like make -j8. i.e. provide a -j cli arg for people who need it. And set default value to no. of cores.

What

We have received a request for support for the BSD environment, and we assume that the gup command will work in any environment where golang is available. Therefore, we would like to unit test gup in a BSD environment.

How

Create a Github Actions workflow for unit testing in BSD environments such as OpenBSD, FreeBSD, NetBSD, etc.

Why do I want help?

1. I am not a BSD user. I use Linux and Mac. There is no benefit for me to support BSD. The fact that gup command supports Windows is just a coincidence. I added Windows support to learn cross-platform compatibility.
2. I don't have the time. Since my child was born, my development time has decreased. It is difficult for me to increase the number of supported operating systems on my own.
3. The gup command probably works on BSD. I haven't tested it, though...

gup is a very simple command, so I don't think all users need shell completion files. Also, Cobra has completion subcommand support even for PowerShell, and it would be enough for most use cases.
Is there any reason to disable Cobra's feature and re-implement similar feature? Even if yes, I think it should be optional.

gup version**

gup version v0.20.0 (under Apache License version 2.0)

Description / Steps to reproduce

I noticed on my system that gup reports an error about the .DS_Store file:

$ gup update
gup:INFO : update binary under $GOPATH/bin or $GOBIN
gup:ERROR: [ 1/12] .DS_Store is not installed by 'go install' (or permission incorrect)

Expected behavior

Skip this hidden / OS metadata file (I think by default gup should ignore any dotfiles?)

What

Add an action for unit-testing on Windows and macOS in the actions.

This allows us to ensure the source can be compiled on most of the platforms (Linux, Win, macOS).

How

name: PlatformTests

on:
  workflow_dispatch:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  unit_test:
    name: Unit test

    strategy:
      matrix:
        platform: [ubuntu-latest, macos-latest, windows-latest]

    runs-on: ${{ matrix.platform }}

    steps:
      - uses: actions/checkout@v3

      - uses: actions/setup-go@v3
        with:
          go-version: '1'
          check-latest: true

      - name: Run unit test
        run: |
          go mod download
          go test -race -v ./...

Describe the bug
The configuration base directory is hardcoded to $HOME/.config. This is a reasonable fallback, but ideally it would respect the XDG_CONFIG_HOME environment variable as specified in the XDG Base Directory Specification:

$XDG_CONFIG_HOME defines the base directory relative to which user-specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

To Reproduce
Simply invoke gup and the $HOME/.config/gup directory will be created, including the parent $HOME/.config directory if it doesn't exist. This occurs even if $XDG_CONFIG_HOME is set and specifies a different path for program configuration data.

Expected behavior
Respect $XDG_CONFIG_HOME if it's set and usable (writeable directory or we can create one at the location). If it's not set, or there's a failure of some form, fallback to $HOME/.config. A warning specifying what went wrong should be printed if $XDG_CONFIG_HOME is set but we're unable to use it for some reason.

Desktop (please complete the following information):

• OS: Windows 11 (but the specification is cross-platform)
• Go Version: 1.19.5
• Application Version: 0.15.1