Allow package to specify Python version

[BrandonLWhite]

Background: I'm supporting a CLI tool built on Python3.6, that is used by non-developers. As such, pipx is very attractive for making this hassle free for the users of the tool. At this time, pipx is using Python3.8 when installed with brew install pipx. This leads to an error of ERROR: No matching distribution found for dataclasses==0.7 when subsequently using pipx install on my CLI application.

The particular error I'm facing is probably irrelevant. I can imagine that there are other snags that could come with a surprise Python3.8 runtime.

I see that pipx install allows for a --python version switch. That seems like it will get me out of the woods for now. However, it occurs to me that requiring my end users to add this switch (and then down the road, probably updating it to 3.7, 3.8, etc) is not quite in line with the mission of pipx.

This request is to propose a way for a CLI application to expose its required Python version and for pipx to install and run it CLI with that version. That would make it easier for my end-users now and in the future when we are able and want to use a later Python version.

[uranusjr]

The challenge of this feature, from what I can tell, would be to match Python versions (which is what packages can specify with requires-python) cleanly to Python executable paths (which is what pipx needs to create virtual environments). pipx will also need to detect all installed Python versions, so for (say) >=3.6 it can choose 3.8 over 3.7.

There are existing means to do this (e.g. virtualenv has an implementation to map version to executable path; the Python Launcher on Windows can collect versions from registry), but everything is quite ad-hoc in this area. I would say this is a very sensible feature to have, but the Python ecosystem does not have enough means yet to get it done.

[johnklehm]

Would it be reasonable to build this out with pyenv/asdf in mind? That would allow a large number of python users to make use of this feature.

[uranusjr]

That goes back to the ad-hoc nature of Python version detection we can currently do; both pyenv and asdf introduce even more tool-specific behaviour that needs to be special-cased, and that approach won’t scale well. IMO the design should be the other way around—someone should propose a central registration format (like PEP 514 but for POSIX systems), make pyenv etc. register to it, and pipx can then just read that registry to know where to find what versions. This needs to involve much more than just pipx; I would suggest raising a topic on https://discuss.python.org, I think some people there would be very interested in this.

[johnklehm]

I agree that's the right move long term, it's likely a long process though.

[uranusjr]

And it will only be longer while we are here not making progress of it. I'd encourage staring a conversation somewhere (python-ideas, or discuss.python.org) on the topic.

[johnklehm]

Done: https://discuss.python.org/t/provide-a-pep-514-like-registry-for-all-supported-platforms-windows-macos-posix-variants/8684

I'm not sure what the way forward here is, create a pep514-all-platforms project, abstract the most common tooling for the given platform behind an interface that was as similar as possible to what's been established on windows? Then come back to you here with a PR against that abstraction?

[johnklehm]

For now I'm working around this with a shell function:

pipx-install-w-python-ver () {
    _python_version=$1
    shift
    _prev_python_version=$(python --version | cut -d" " -f2)
    asdf shell python $_python_version
    python --version
    python -m pip install pipx
    python -m pipx install "$@"
    python -m pip freeze | xargs python -m pip uninstall --yes
    asdf shell python $_prev_python_version
}

Example:

$ python --version
Python 3.9.4
$ pipx-install-w-python-ver 3.8.8 xonsh
.
.
.
$ pipx list | rg xonsh                 
   package xonsh 0.9.27, Python 3.8.8
    - xonsh
    - xonsh-cat

[gaborbernat]

One could use here virtualenv and its python discovery mechanism as good enough for now. PR welcome.