Perhaps some of these "how do i even install the dependencies to run the software as a new user on platform x using package managers y and z " problems could be avoided by distributing a self-contained and tested Stan container image with pinned versions of dependencies (compilers, libraries, etc) atop a supported base image (e.g. debian stable).
I see earlier this year @wm1995 shared an example Dockerfile that installs pystan3 atop a python:latest image, which appears to be based on debian 11 bullseye, which is one of the operating systems supported by pystan:
With a container image there would still be a bit of a learning barrier for new users unfamiliar with wrangling container images: e.g. how do i run a container image locally (in this case installing docker for mac or perhaps an alternative like podman), how do i configure volume mounts and port forwarding to be able to share data and source code with a container or view a notebook hosted in the container – but there would no longer be any opportunity for users to accidentally pick combinations of build environments and package managers that aren’t supported or don’t work.
I just want to echo the above, I’ve tried pip install pystan from two different virtual environments (virtualenv and pipenv) on MacOs 10.14 with two different versions of Python (3.8.8 and 3.9.5) and in every case, with two different pip versions (20.2.3 and 21.3), none of them are able to install pystan 3.x, every time it falls back to 2.19.