Support configuring Python interpreter paths for different Python versions in .pdm.toml

[laike9m]

Is your feature request related to a problem? Please describe.

pdm use requires users to manually select the interpreter path. When users need to switch between different Python versions often, this operation quickly becomes tedious.

Describe the solution you'd like

IMHO, it makes sense to let users configure the interpreter path for different versions of Python. Reasons are

• Saving human effort
• The interpreter paths seldom change, so prompting the selection every time is not so necessary. We can prompt only if the path is not configured.
• .pdm.toml already supports setting python.path, but only to the current interpreter being used. This proposal is about enhancing the existing feature to make it more useful.

[frostming]

I've received another similar FR about this privately, but it proposed a different solution: Add a configuration item specifying the location to find Python interpreters, say you configure it as the pyenv home so that only pyenv pythons are listed. Because pyenv usually has only one Python for a given version, it should solve your problem?

[pawamoy]

Maybe pyenv is not the right example though, because you can already configure it to expose only one version of each minor version (pyenv global 3.6.8 3.7.8 3.8.8 3.9.6 3.10.0), so pointing PDM to its shims seems redundant.

[laike9m]

I've received another similar FR about this privately, but it proposed a different solution: Add a configuration item specifying the location to find Python interpreters, say you configure it as the pyenv home so that only pyenv pythons are listed. Because pyenv usually has only one Python for a given version, it should solve your problem?

Not exactly.

First, even if we limit the search scope to pyenv's directory, there are still multiple binaries to choose from

Second, the solution we pick should be generic enough to support all ways Python can be installed. The format of configuration doesn't have to be version -> path_to_binary, but at least this is one way to make it work no matter how Python is installed (and TBH I can't think of other ways to achieve this, maybe you can).

[frostming]

Configuring the version -> path_to_binary is a big effort which I wouldn't like to do. What I can suggest is to remember the last choice in pdm use <python> with the key <python>. And of course, offer an option to pdm use to ignore the caches.

[laike9m]

Honestly, I don't think only memorizing the result of pdm use is gonna be very useful, at least it doesn't solve the pain points I have.

I don't expect to change your mind immediately, but hope we could at least agree that

1. Even if add we support this config (which is disabled by default), it will be transparent to most people, and nothing will change for them.
2. For people who need to switch between versions often, this is a HUGE usability improvement.

Configuring the version -> path_to_binary is a big effort which I wouldn't like to do

My guess is that your concerns are mainly around the complexity of implementation. Mind explain?

[frostming]

Let me understand, the key point that makes you prefer configuration rather than memorizing is, em, transparency. Is it true?
Because the only difference is the memorizing method doesn't need extra user input but loses some transparency. Or am I missing other concerns on this?

[laike9m]

Configuring the version -> path_to_binary is a big effort which I wouldn't like to do. What I can suggest is to remember the last choice in pdm use with the key . And of course, offer an option to pdm use to ignore the caches.

Sorry for the confusion, seems my previous understanding was wrong. To make sure I understand, in your proposal, pdm can remember the mapping from version -> path, but the mapping is implicit instead of explicit. And this is the only difference from my proposal. Is that correct? If so, I'm fine with it.