我在我的工作笔记本上使用pipx，除其他地方外，我今天把它从Fedora 34升级到Fedora 35。之后，我的单个pipx安装的程序不工作，这基本上是我所预料的，因为熟悉的pip问题与Python版本有关；Fedora 34有Python 3.9，而Fedora 35有Python 3.10。由于一个的虚拟环境不能与另一个一起工作，所以我安装的程序的虚拟环境找不到已经安装在其中的任何Python包。
因为我以前用'pipx reinstall'成功过，所以我认为解决这个问题的方法是进行重新安装。不幸的是，这导致了一个惊人的失败，pipx删除了我的虚拟环境，然后未能重新创建它，出现了pip 不可用的错误。由于最初的删除丢失了我所安装的程序的pipx元数据，所以不容易恢复，而且无论如何'pipx install'也有'pip不可用'的问题。 归根结底，这似乎是因为pipx在~/.local/pipx/shared ，它有一个或多或少隐藏的虚拟环境，在那里放置共享的东西，关键是包括pip本身。这个虚拟环境也与特定的 Python 版本绑定在一起；如果你改变了你的 Python，它也会停止工作，这意味着任何指向它的每个程序虚拟环境也会停止工作。
(你可以在每个 venv 的 lib/python3.X/site-packages/ 目录下的 pipx_shared.pth 文件中找到这种迹象，它有这个共享 venv 相关部分的绝对路径。 注意，这意味着如果你改变了你的主目录或者把它们复制到另一个有不同主目录的系统中，你的 pipx 安装的 venvs 可能会失败，因为它们有这个共享树的绝对路径。)
在我的笔记本电脑上，我通过完全删除~/.local/pipx的蛮力解决了这个问题，但我只有一个程序通过pipx安装。我做了足够多的实验来确定，如果你删除 ~/.local/pipx/shared (或重命名)，pipx 会重新创建它，但我不知道这是否会通过一个完整的已安装的 Python 版本升级过程来实现。如果是这样，我想你需要做的是升级你正在使用的 Python，删除 ~/.local/pipx/shared，然后执行 'pipx reinstall-all'。
这显然是一个 pipx bug，它应该自动检测到一个过时的共享区域并重建它，但我们处理的是我们现在的 pipx，而不是我们希望的 pipx。
PS：虽然pipx没有向你暴露这一点，但你可以通过运行~/.local/pipx/venv//bin/python，在任何已安装程序的虚拟环境中获得一个Python shell。如果你想做一些事情，比如检查 Python 的sys.path 设置，这可能很有用。
