Those will likely cause more problems (as per https://xkcd.com/927/ https://xkcd.com/927/). While bootstrapping Python is a problem, it's a symptom, not a cause

Those will likely cause more problems (as per https://xkcd.com/927/ https://xkcd.com/927/). While bootstrapping Python is a problem, it's a symptom, not a cause. The underlying cause is there is a substantial part of the ecosystem (of which the "data science" component overlaps with) that is coupled to hardware, the OS and external (non-Python) software libraries which doesn't align well with the single-language approach that a part of the Python community wants (vague gesture to the "web dev" side of the community). This drives the pip vs. conda arguments, the discussion around docker, nix, homebrew etc. You can't tool your way out of this divide over what the community wants (and while there are two vague meta-groups, there are really sub-groups which want different aspects of both). It's worth looking at how some other popular languages (don't) handle this: from what I've seen, CGo is generally frowned upon, and so there is rewrites of libraries into go (Python does the same), or network/IPC connections are used to bridge the game; Rust also has the rewrite attitude, but for bridging to other languages there's build.rs (which calls other tools and wrappers), but those usually require you have the external library already installed (via some other means e.g. homebrew), or at least don't feature as a self-contained part of the cargo ecosystem (there's a cargo plugin which downloads a version of the library from somewhere); nodejs seems to either try to build from source (which fails if you don't have Python install for gyp), or download random binaries which sometimes work.