PackagingCon event

Packaging
4

I’ve been pondering on giving an overview on Python packaging, focusing on why we end up where we are and the different approaches Python takes from some other ecosystems. Each topic takes roughly the form of:

  1. Raises of question why we do something different from everyone else.
  2. Historical reasons behind the difference.
  3. The advantage (to Python) of the approach chosen.
  4. If it’s possible to overcome the disadvantage, and how.

Currently I have 3+1 topics:

Per-artifact metadata (instead of per-version)

  1. Why is metadata distributed with each artifact (distribution) and can differ within the same version?
  2. Python packages predate indexes. PEP 508 direct URL is a thing.
  3. A user does not need a package server to host Python packages.
  4. Sort of. The community is gradually forming consensus some metadata shouldn’t differ. PEP 658.

Pull-based platform declaration

  1. Why does PyPI not automatically builds wheels for every project (besides the cost issue)?
  2. Python does not have a “support tier” concept like many platforms.
  3. A platform is “supported” if you can manage to build a Python interpreter on it. Very good for the community to grow.
  4. Feature detection, but there are always edge cases.

Installation metadata and installed files side-by-side

  1. Why are Python package metadata stored directly beside the package installation, instead of living in a central location?
  2. That’s the only “official” place for third-party tools to store stuff, and all Python packaging tools are third-party.
  3. Easy discovery, especially easy to write tools to find them and guarantee the result is correct (if you find the code, you find the metadata).
  4. Are there real technical downsides…?

Meta question (conclusion-ish)

  1. Why does Python packaging do things weird?
  2. Python packaging contributors and Python contributors have surprisingly little overlap and historically receive relatively little effort.
  3. Packaging contributors have more freedom doing what we want.
  4. Overhead when discussing changes in the interpreter. Focus more on standards instead of specific tools to gather more people.

I have not submitted the proposal and honestly am still not entirely sure I want to. Update: I’ve submitted this with the title Python Packaging: Why Don’t You Just…? This page shows the proposal publicly if I’m not mistaken.

If you have a topic along a similar line that I do not cover, feel free to suggest one. I anticipate the conference will probably gather people interested in packaging from all sorts of communities, so the attendee may be interested in hearing why another community doesn’t do things like they do. I’ll also avoid sounding snobby to other communities (e.g. why are Python packages so difficult to compile? Actually they aren’t, but Python is more widely used on more things than most language so you see more exotic stuff).

7 Likes