[Bug] qmk setup -H <path> ignores <path> but still uses user.qmk_home read from .config/qmk/qmk.ini

Describe the Bug

Context

This is running on Xubuntu 22.04, using qmk gotten using:

python3 -m pip install qmk

I'm using the instructions found here: https://github.com/zsa/qmk_firmware/#building:~:text=head%20to%20the%20Newbs%20guide%20from which is based upon QMK, and thus I found the defect originating from QMK and not those instructions, and not specific to the zsa/qmk_firmware keyboard(s).

Steps to reproduce

Execute qmk setup zsa/qmk_firmware --yes -b firmware22 -H qmk_firmware

And then .config/qmk/qmk.ini gets written with:

[user]
qmk_home = /path/to/my/current/working/directory/qmk_firmware

Then move your home directory to a new disk such that the /path/to/my/current/working/directory/ is or should be considered to be no longer valid. This occurred due to a disk failure whereby I had to move some links around such with the net effect that readlink -f $HOME before the outage is now different from what it was prior to the previous invocation of qmk setup ... above.

Cd into the new directory where we wish to have the qmk_firmware directory to be installed into, and then again run the qmk setup ... command. Do a ls -l qmk_firmware and be surprised that it does not exist.

Analysis/speculation

After some debugging, realize that the old /path/to/my/current/working/directory/ actually still does exist but notice the readlink -f above: What I think is happening is that the qmk setup command is just reading the user.qmk_home configuration value from the ~/.config/qmk/qmk.ini file which is still stuck on the old /path/to/my/current/working/directory/ value that still does exist but exists on the old harddrive. And if my theory is correct, the defect here is this: I, the user, specified -H qmk_firmware on the qmk setup command line, yet the old value was still read from the .ini file. This is unexpected: I instead expected that the .ini file value of user.qmk_home to be overridden by the value passed to the -H option, which really means to only use the qmk_firmware as the location, which is relative to the current working directory and not the old value found in the ~/.config/qmk/qmk.ini file.

My hackaround

I hack around this via:

./runenv qmk config user.qmk_home=$$(pwd)/qmk_firmware  # <-- because qmk setup ... -H completely ignores the -H option and continues to use ~/.config/qmk/qmk.ini values.
./runenv qmk setup zsa/qmk_firmware --yes -b firmware22 -H qmk_firmware
ls -ld qmk_firmware  # <-- If this gives a no such file or directory error, then the defect is still extant.

Keyboard Used

zsa/qmk_firmware

Link to product page (if applicable)

https://github.com/zsa/qmk_firmware

Operating System

Xubuntu 22.04

qmk doctor Output

Not applicable, IMO, because if my theory is correct, this is a cart-before-the-horse problem between .ini files and command line options, the latter of which should **override** the .ini values.

Is AutoHotKey / Karabiner installed

• AutoHotKey (Windows)
• Karabiner (macOS)

Other keyboard-related software installed

No response

Additional Context

No response

Start at the qmk setup command and its handling of the -H option, then inspect how user.qmk_home is read from ~/.config/qmk/qmk.ini and how command-line values take precedence. Done means rerunning the reported command after an existing configuration value creates qmk_firmware in the requested current directory rather than using the old configured path.