Python Packaging Strategy Discussion - Part 1

There are a few things to learn from R - for example, CRAN has a build farm and its checks on upload ensure higher-quality packages, plus users seem to like the integration of package install/management in the interpreter. Overall R is more limited in scope that Python though, and I’m fairly sure no one here wants to go back to building from source by default on some platforms.

Other languages and their package managers have lessons too. Julia’s package manager is pretty powerful and yields a nice user experience - as numerical/scientific languages go, it’s the state of the art I’d say, rather than R. And Rust/Cargo for overall experience.

Loudest in this forum I’m sure. The “torn apart” isn’t a useful statement to make, unless you meant “if the goal is to standardize on a single do-it-all thing”. Which I don’t think will happen. We need more unified UX, interfaces and concepts, but under the hood we very likely can’t get away from multiple build systems/backends/frontends, multiple environment and package managers, etc.

I like @pf_moore’s answer a lot. The “want to be their own integrator” users are important (and over-represented on this forum), and that should continue to be supported. However, the average user doesn’t want to do this, they want things to work well without too much trouble. So I’d also go for supporting the existing integrators better.

Like @pradyunsg, I also have more thoughts than fit in a Discourse post - will go write a blog post too:)

3 Likes