SupportedCPythonversions,installationmethods?

Okay, interesting note about the user site-packages dir conflicting with the Python path. I hope you're fine with discussing this further to at least achieve a common understanding.

Based on my current knowledge, I think adding the user site-packages dir to the Python path is a fine design choice for non-isolated virtual environments. Why would it be a problem? Virtualenvs are a hack actually. But most importantly, I could not reproduce this issue in an isolated venv, didn't test it in a non-isolated one.

Really, I think the Node.js shop argument is not very good. I do not see why it would be more difficult or unattractive to issue one or two very plain command line statements vs. one (slightly more complex). Also, the

dependency of the current instructions won't be available on Windows by default and needs to be installed on the CI host.

It's still okay if you think asking to install one or two OS packages on Debian makes things too difficult, but didn't I propose to reserve the special instructions (meaning, even if just the current ones) for Debian? At least, that would not suggest to users that

should always be installed in the unconventional (in my view, unattractive for the reasons stated) way. Also,

as known by the Node.js peeps works in the same way, also installing deps under the user home directory. The same is true for many other language impl dep managers. And on a final note, I'd say

itself is fairly well-known by anyone who ever did anything with CPython, even for some end-user use cases.

I agree that it's attractive to just fire off a script and that sorts out everything for installation. The problem is, this fails in a bare Alpine Linux Docker container, i.e. a common CI host, with cryptic error messages. That's related to #396, and not a problem per se. What I am getting at is that the benefits of keeping your script/custom installation commands that you feel do not bear out in practice for me.