Python Packaging Struggle for pytest Plugins

Recently, Pradyun posted a tweet commenting not on the state of Python packaging, but more on the state of the documentation and guidance.

Now, at the time, I figured that was the case for people new to packaging, not myself. I’m not really an old timer with packaging, but:

• I have a few published packages.
• I’ve used both Flit and setuptools.
• I’ve interviewed Brett Cannon 3 times on the packaging in episodes of Test & Code.
  • 52: pyproject.toml : the future of Python packaging
  • 119: Editable Python Installs, Packaging Standardization, and pyproject.toml
  • 152: Python Packaging
• There’s also a pip interview with Stéphane Bidoul:
  • 163: pip install ./local_directory
• and a couple solo episodes talking about flit:
  • 80: From Python script to Maintainable Package
  • 81: TDD with flit

Mostly trying to say that I’ve followed the story enough that I should be able to figure this out for a new package. At least, for a Python only package, which is really all I’ve done in the past.

My confidence ended this morning.

I tried to put together another pytest plugin today.

Trouble in flit paradise, at least for pytest plugin authors.

• For Python source only packages, Flit has been my goto for some time.
• pip install flit, flit init produces a starter pyproject.toml.
• It’s always gotten the name wrong if you want a dash in the name, like pytest-myplugin, but it’s been a simple enough change to fix it.
• Until … DUN DUN DUUUUN!!! (Dramatic Sound Effect) … flit 3.2 and New style metadata
• I actually like where flit is going with this, more toward standardized metadata.
• But … DUN DUN DUUUUN!!! (Dramatic Sound Effect) … it doesn’t work yet for plugins. It makes it worse.
• flit init creates a new style metadata