-
Notifications
You must be signed in to change notification settings - Fork 398
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
Comments
The challenge of this feature, from what I can tell, would be to match Python versions (which is what packages can specify with There are existing means to do this (e.g. |
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. |
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. |
I agree that's the right move long term, it's likely a long process though. |
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. |
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? |
For now I'm working around this with a shell function:
Example:
|
One could use here virtualenv and its python discovery mechanism as good enough for now. PR welcome. |
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 ofERROR: 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.
The text was updated successfully, but these errors were encountered: