Feature request: when uninstalling python version the patch version could be not specified

[detrin]

When uninstalling python version e.g. pyenv uninstall 3.7.14 we have to specify also the patch version 14. When we have only one patch version installed for a particular major and minor release of python do we really need to specify the patch version? I suggest:

1. if there is only one installation of python for a particular major and minor release, e.g. 3.7
2. in order to uninstall the particular version, e.g. 3.7.14 we can use either pyenv uninstall 3.7.14 or pyenv uninstall 3.7

[native-api]

This was done deliberately because with automatic prefix resolution, you're risking accidentally deleting an installation other than the one you want.

To explicitly order Pyenv to resolve a prefix, use pyenv latest. E.g.:

pyenv uninstall $(pyenv latest 3.7)
# or
pyenv latest 3.7 | xargs pyenv uninstall

[native-api]

Btw if your goal is to save typing, pressing <Tab> after 3.7 would resolve it to 3.7.14 if it's your only installation beginning with those characters. (That's assuming you have Pyenv shell integration active.)

[detrin]

This was done deliberately because with automatic prefix resolution, you're risking accidentally deleting an installation other than the one you want.

To explicitly order Pyenv to resolve a prefix, use pyenv latest. E.g.:

pyenv uninstall $(pyenv latest 3.7)
# or
pyenv latest 3.7 | xargs pyenv uninstall

I understand it can be done in such way, but all of those options use more than just one command.

[detrin]

Btw if your goal is to save typing, pressing <Tab> after 3.7 would resolve it to 3.7.14 if it's your only installation beginning with those characters. (That's assuming you have Pyenv shell integration active.)

Sure, but you have to know that the Tab completion works in this particular case. Which may seem obvious to maintainers, but not to someone who uses pyenv once in a while like myself. Besides that the feature I am requesting does the same without Tab which feels more intuitive to me.

This was done deliberately because with automatic prefix resolution, you're risking accidentally deleting an installation other than the one you want.

However, when we have only one patch version installed, I don't see how does this apply here.

[native-api]

However, when we have only one patch version installed, I don't see how does this apply here.

Indeed, in this particular case, it doesn't.

It does in the cases where

• you think you have something specific installed but the reality is a little bit different (especially probable in scripts)
• the prefix resolution happens to work differently in the particular case than you're expecting it to (can very well happen with prereleases and alternative Python flavors with different versioning schemes)

I just foresee an influx of complaints from users who accidentally deleted something important by falling victim to the above scenarios. They would (IMO rightfully) think that we've left a landmine for them to step on.

[detrin]

I can't comment on how many users will fall victim for those two scenarios you mentioned. I am not maintainer and I don't know what ppl use to come here with to complain about.

Would you consider at least in case is user want to delete python version, e.g. 3.7.14, but writes only pyenv uninstall 3.7 pyenv telling him "Hey the version 3.7 is not currently installed, but you have versions 3.7.1, 3.7.3, ... 3.7.14, ..." Plus when the user has only one patch version it will also add to the message "You can complete the version of 3.7 to 3.7.14 by pressing Tab next time."?

[native-api]

Tab completion is already mentioned in https://github.com/pyenv/pyenv?tab=readme-ov-file#set-up-your-shell-environment-for-pyenv .
Perhaps we can make the mention more prominent (e.g. explicitly call it "tab completion")?

Tab completion -- and the ability for programs to integrate with it -- is built into most shells and always behaves in the same, shell-specific way. So I doubt it warrants more elaboration that that: it's already being explained in learning materials for the shells. Pyenv documentation is not the place to teach users to use shells.