According toastral-sh/python-build-standalone#382, you might be able to use whatuv uses:https://github.com/astral-sh/uv/blob/c25c800367a5f43069f1c9d778cfd5de1bcc54a6/crates/uv-python/python/get_interpreter_info.py#L639-L645 (i.e.,sysconfig values).

Is that more helpful?

I think we should catch the error, not exclude python-build-standalone per-se. If they'd fix the tk issue, our versions would directly work. Onis_uv_python - I've explicitly tested for uv and tailored the error message, because I anticipate that'll by far the most route to trigger this, and I project that most uv users will not know what python-build-standalone is. So let's give them a uv-targeted error message.

I didn't suggest excluding python-build-standalone, just detecting it differently.

My point is I do not really care about python-build-standalone. The criterion is 1. does it raise the known error? And if so, is it a uv-install that I can point users to as the practical cause.

If that's the case that you only care aboutuv, then the PR/commit title should be adjusted.

Possibly my wording was not exactly precise.

The issue originates from thecurrent way python-build-standalone is implmented. - So the PR title is justified.

Then there are two aspects to handling:

1. Detection: I want to detect the specific error and respond to that. - It's not helpful to detect python-build-standalone. They may improve to fix the error in the future. So issuing a warning/error purely on the fact that python-build-standalone is used would be presumptuous.

2. Error message: In the simplest case, we could just have the second error message

   Failed to import tkagg backend. This is likely caused by using a Python executable based on python-build-standalone, which is not compatible with Tk. Please use another Python interpreter or select another backend.

   (or if you want to be more affirmative explicitly test for python-build-standalone and remove the "likely"). However, the by-far most common way to obtain a python-build-standalone python is viauv. But it's a technical detail ofuv and users are most likely not aware of it. So telling them, they have python-build-standalone is not helpful for fixing the issue. Therefore, I added theuv detection to tell them that uv-provided python is not compatible.

I am 👍 on doing the work to detect if it is uv.

This should be updated too to mention that a newer python-build-standalone version will fix this - for users of other tools (Poetry, mise, Bazel rules_python, etc.) there should be a path forward without changing the tools and workflow they're using, though it's not practical or necessary to specifically document what exactly they should do to upgrade.

(Also, if you're editing this, small nit above - I would specifically say that you're using anoutdated Python version, now that current uv-installed Python versions are compatible with Tk.)

I think this is fine, but just so you're aware,uv self update won't be available for users that have installed uv through their package manager instead of the standalone installer. A more "general" solution would be to "upgrade to the latest version of uv then useuv python upgrade --reinstall"