The 10+ year view on Python packaging (what's yours?)

I do fear this could lead to a snarl of dependencies that would become even harder for people to unravel when they encounter problems (if I pip install with python I installed via an npm I installed with conda where does that package go??).

A version of this I think might be somewhat more attainable is if a packaging tool could delegate to a more specific tool–i.e. if all you’re going to do is install a wheel, then delegate that installation to pip [1].

We can sort of see this in the conda ecosystem–many recipes are just wrapping the PyPI package with metadata. conda list will tell you if a package came from pip but it doesn’t recognize those as “already installed”.

I feel like delegation is more attainable than agreeing on an interoperable standard[2], because a tool like pip could define its own delegation interface and let other tools adopt it if they want to [3]. Talking to the relevant parties can’t hurt, but it doesn’t require a consensus to demonstrate value.

Perhaps this is already possible in the interaction between conda and pip, for instance, but it’s not quite how it works right now (and I’m sure there are good reasons why it’s difficult)


  1. or a hypothetical future Unified PyPA Tool, if one arises ↩︎

  2. there are just so many differences of opinion about How Things Should Be ↩︎

  3. or rather, I should say that a PEP could define this for python packaging ↩︎

1 Like