3 ms·

The short term solution is "relieving the packaging pain" link in the article. The long term solution is described in the "What a solution could look like?" s

The short term solution is "relieving the packaging pain" link in the article. The long term solution is described in the "What a solution could look like?" section of https://www.bitecode.dev/p/why-is-the-python-installation-process https://www.bitecode.dev/p/why-is-the-python-installation-pr... The community is buzzing with attempts to fix those issues this year, so I’m hopping those posts will become obsolete one day. Flask’s author is attempting something interesting with rye: https://github.com/mitsuhiko/rye https://github.com/mitsuhiko/rye Trio’s author is drafting a spec for the equivalent of wheels, but for the whole python interpreter: https://github.com/njsmith/posy/blob/main/pybi/README.md https://github.com/njsmith/posy/blob/main/pybi/README.md Not advocating to use them right now, but the fact is bootstrapping Python is finally acknowledged as one major cause of packaging issues and a priority to solve.

aragilar 3y ago
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.

aragilar 3y ago

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.