Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow package to specify Python version #387

Open
BrandonLWhite opened this issue Apr 9, 2020 · 8 comments
Open

Allow package to specify Python version #387

BrandonLWhite opened this issue Apr 9, 2020 · 8 comments
Labels
help wanted Extra attention is needed

Comments

@BrandonLWhite
Copy link

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
Copy link
Member

uranusjr commented Apr 9, 2020

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
Copy link

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
Copy link
Member

uranusjr commented Apr 20, 2021

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
Copy link

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

@uranusjr
Copy link
Member

uranusjr commented May 4, 2021

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
Copy link

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
Copy link

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants