[Proposal] Isn't the first prompt of pdm init confusing?

[ghost]

First of all, thank you very much for this great OSS.

At first time you command pdm init, you'll see this prompt.

I honestly get confused because,

1. I don't remember python interpreter in each machine (I now know this prompt doesn't require absolute path, but it doesn't mention).
2. create-react-app or any other kind of famous library shows the choices without prompt. I think many users get used to those kind of behavior.

Therefore, I created branch for this proposal below.
master...ulwlu:skip_first_prompt_at_init

This shows choices at first time, so users easily choice what they want to use.

I'd like to know what you think about this, and if positive I will create news as well and send this PR.

[frostming]

I made that prompt to narrow down the range of interpreters, but I admit your solution is better from the user experience perspective. I have no strong objection against this, it is okay.

[ghost]

Thank you for your reply. Then I'll send PR later.

[baggiponte]

About this: I am using pyenv to manage python versions. When I pdm init I get the python set as global with pyenv, as well as the others installed in other ways (say, system and homebrew):

However, I would not want to have these homebrew/system interpeters show up. Would it make sense to add a config such as 'python_interpreters_dir" - where, if set, PDM would look at exclusively to find the interpreters?

[noirbizarre]

I don't want to necrobump this thread but in my case I have both pyenv and asdf as well as a lot of venvs producing very long output on this screen requiring paging/scrolling to see the first proposal.

So I explored multiple proposals I share here.

2 steps choice

This approach have a first "which major/minor" do you want to use then select in a filtered subset.
The 2nd prompt only appear if there is more than one choice.

Variants for the second step:

• don't prompt and choose the first version matching the major/minor or the one with the higher patch
• well knowns priorities: assume than we can triage interpreter by source (system, asdf, pyenv, brew, current venv...) and decide of a priorisation based on this, something like "take the more recent and if there is multiple matches chose the first cascading asdf, pyenv, system...)
• user config picking strategy: instead of a well known approach (priosation provided by PDM), this is the opposite: the user define in its PDM setting the cascading order he want to apply and maybe a strategy (system first then higher version, only pyenv, higher version first then cascade....)

keep the current interpreter by default

This one is quite simple: if the current interpreter match the Python requirement, don't prompt and use it: the user can change later with pdm use if is not satisfied.

[frostming]

If we do not provide enough flexibility for the interpreter selection I'm afraid users will keep asking why to pick this and not others.