Bump userpath to 1.9.0

[dukecat0]

• I have added an entry to docs/changelog.md

Summary of changes

Bump userpath to 1.9.0

Test plan

Tested by running

# command(s) to exercise these changes

[uranusjr]

Why do we need to raise the lower bound?

[chrysle]

I guess because of ofek/userpath#48 and #996.

[safl]

Hmm, have you considered that userpath v1.9.0 breaks automation use-cases?
Specifically I have this issue: ofek/userpath#50 with it.

I would propose:

userpath>=1.6.0<=1.8.0

This is an issue as-is, when installing pipx via pip as it grabs the latest userpath module, and thus renders cli-tools installed via pipx and PATH-updated with pipx ensurepath unusable.

[uranusjr]

I don’t feel adding an upper cap would be a good idea since it would require a new release when say 1.10 come out. You can add that upper limit yourself if it suits your use case, but someone else can’t remove one if that doesn’t work for them.

[safl]

I don’t feel adding an upper cap would be a good idea since it would require a new release when say 1.10 come out. You can add that upper limit yourself if it suits your use case, but someone else can’t remove one if that doesn’t work for them.

• An upper-bound would prevent a functional regression like the one that is happening right now

  • A new release of pipx would not be required when userpath is released, unless it provides functionality needed by pipx. What could have happened here is that someone might have said "oh wait, bumping userpath to v1.9.0 introduces a regression in the behavior of pipx ensurepath, let's resolve that before bumping". Or, if there were tests for non-login shells, then they would catch it. Rather than the functional regression seeping into pipx.
  • I guess it is a trade-off between "conveniently" getting third-party code bumped automatically with the risk of pipx sporadically breaking / altering behavior (for the same version of pipx) vs the chore of verifying changes to third-party code with the upside of stable / non-altering behavior (for the same version of pipx)

• I cannot control the version of dependencies when installing pipx via the system package manager

  • With the introduction of https://peps.python.org/pep-0668/ then pipx is a convenient way to manage command-line tools implemented in Python. However, with the regression introduced by userpath v1.9.0 then it no longer applies for non-login shells, so basically if you run your commands via SSH-exec (ssh user@host "my_command").
  • Installing pipx via the system package manager is a really convenient way to bootstrap the availability of Python-based command-line tools and with pipx ensurepath even more so
  • Thus, for example on Debian, when https://packages.debian.org/bookworm/python3-userpath is upgraded to v1.9.0, then using pipx ensurepath won't be usable for non-login shells any longer, I won't be able to fix that.
  • As I understand the motivation behind userpath dropping non-login shells, then it was not because something was "not working" but rather that it was "not nice that there where duplicate entries in the PATH variable. I might be wrong, but I just weigh functional regressions higher than nice-to-haves.

I have opened up issue #1025 to better describe the use-case.

[dukecat0]

Why do we need to raise the lower bound?

Originally I thought this would fix #978 and #1007, but seems like now it can lead to more issues, so I am closing this PR.