Improve UX when PATH-resolved plz binary differs from updated version

[sean-]

Summary

• Suppress the "Upgrading Please from version X to Y" message when the target version already exists in ~/.please/. Previously this printed on every invocation when the PATH binary (e.g. from Homebrew) was older than the pinned version, even though no download was needed.
• After plz update, warn if the binary resolved by PATH is not the one that was just updated. This helps users discover that e.g. /opt/homebrew/bin/plz is shadowing ~/.please/plz and they need to fix their PATH.

Reproducer

# With /opt/homebrew/bin/plz (v17.0.0) first in PATH
# and ~/.please/17.29.1/ already installed:

mkdir -p /tmp/plz-repro
cat > /tmp/plz-repro/.plzconfig << 'EOF'
[please]
version = 17.29.1
EOF
cat > /tmp/plz-repro/BUILD << 'EOF'
genrule(
    name = "hello",
    cmd = "echo hello > $OUT",
    outs = ["hello.txt"],
)
EOF

cd /tmp/plz-repro
plz --version          # Please version 17.0.0
plz build //:hello     # "Upgrading Please from version 17.0.0 to 17.29.1" (every time)
plz --version          # Still "Please version 17.0.0"

[toastwaffle]

I'm not sure I follow what the problem is here are you trying to force Please to be used at whatever version Homebrew installs?

We don't expect ~/.please to be in the path at all; whatever you have installed as plz on your $PATH (be it pleasew, please_shim, or an actual full Please binary) takes care of ensuring that the version you want (according to the repository config) exists in ~/.please, and then execs it

For all we care, the installed plz resolved on your $PATH can be Please v1.0.0, but if your .plzconfig specifies version = 17.29.1 that's the version which will be used to execute your build (and if you don't specify that, the default I think is to use the latest available version).

[sean-]

The bootstrap/exec model makes sense and the correct version does end up running the build. The issue is purely a UX one. Here's a minimal repro:

# Setup: /opt/homebrew/bin/plz is v17.0.0 and appears first in PATH
# ~/.please/17.29.1/ already exists from a prior update

mkdir -p /tmp/plz-repro
cat > /tmp/plz-repro/.plzconfig << 'EOF'
[please]
version = 17.29.1
EOF
cat > /tmp/plz-repro/BUILD << 'EOF'
genrule(
    name = "hello",
    cmd = "echo hello > $OUT",
    outs = ["hello.txt"],
)
EOF

cd /tmp/plz-repro
plz --version          # Please version 17.0.0
plz build //:hello     # "Upgrading Please from version 17.0.0 to 17.29.1"
plz build //:hello     # Same message again
plz --version          # Still "Please version 17.0.0"

The current results are:

$ cd /tmp/plz-repro
$ plz --version
Please version 17.0.0
$ plz build //:hello
Upgrading Please from version 17.0.0 to 17.29.1
Build finished; total time 10ms, incrementality 100.0%. Outputs:
//:hello:
  plz-out/gen/hello.txt
$ plz build //:hello
Upgrading Please from version 17.0.0 to 17.29.1
Build finished; total time 10ms, incrementality 100.0%. Outputs:
//:hello:
  plz-out/gen/hello.txt
$ plz --version
Please version 17.0.0

The build works correctly every time — 17.29.1 runs it. But:

1. plz --version always reports 17.0.0 because that's the homebrew binary
2. Upgrading Please from version 17.0.0 to 17.29.1 prints on every single invocation, even though 17.29.1 is already installed in ~/.please/
3. plz update says Up to date (version 17.29.1) but plz --version immediately after says 17.0.0

None of this is broken, but it's surprising. A user who sees Upgrading on every build naturally thinks something is wrong, and the --version / update mismatch is confusing.

A small warning after plz update pointing out that the PATH-resolved binary differs from the updated one would help users understand what's going on and how to fix it.

And actually, let me also fix that second part, too. Now, when the target version already exists in ~/.please/, we skip the Upgrading Please from version X to Y message. Currently it prints on every non- plz update invocation because the bootstrap binary's version doesn't match the config, even though the target is already downloaded and just needs to be exec'd. This makes the common case silent.