Python Packaging Strategy Discussion - Part 1

[pradyunsg (Pradyun Gedam)]

@h-vetinari

Well, the sky’s the limit really, but off the top of my head:

• enforcing metadata consistency / accuracy

I’m not sure what you’re referring to but… to the best of my knowledge, this isn’t a CPython concern. We do need to enforce elsewhere in the toolchain.

@h-vetinari

• using that metadata to do useful things in the python ecosystem
  • for example: regularly run CPython main against the ecosystem (compare Rust’s crater runs, or scala’s community build), identify regressions early, make them release blockers

Outside of the scale issue with trying to run/test CPython against the ecosystem^[1], this is work that redistributors like Red Hat do already, as well as maintainers for various projects (eg: Cython) – and issues are treated as release blockers as and when appropriate. I don’t see how adding more work on the volunteers who maintain CPython is going to meaningfully change things.

@h-vetinari

• solving the “I have to run arbitrary untrusted code” to install a package problem

This isn’t a CPython concern, it’s an installer one: Speculative: --only-binary by default? · Issue #9140 · pypa/pip · GitHub

@h-vetinari

• preventing very confusing splits like venv vs. virtualenv

This goes to, somewhat, the core of what we’re supposed to be discussing here: unifying tools/terminology etc.

@h-vetinari

• remove major installation footguns with the same urgency as other big UX problems (like pip not having a resolver for years and/or how easy it is to mess up your base python install)

This would be nice – if CPython decides to go down the route of trying to have a single “official” cross-platform installation + invocation experience, that’ll make some of our problems less bad… but it won’t fix many of the issues we see.

@h-vetinari

• use “happy path” defaults that solve the 90% case, leave expert mode to explicit opt-in

That’s unrelated to CPython and, honestly, I’d prefer to have this be the case and consistently document this.

@h-vetinari

• bring PyPA and SC much closer together

Would be nice, but also, not going to go into this to avoid derailing the discussion. x-ref Adopting the concept of "Teams" (from PEP 8015)

---

On CPython + PyPA relationship, I noted down my understanding over the weekend. I suggest that this conversation (about CPython / PyPA relationship) get split into its own discussion.

---

1. And the various challenges like not having a consistent test runner experience. ↩︎