PDM does not implement PEP 582, at the time of writing

Note: I’ve updated this to reflect how this happened, on recommendation from PDM’s author.

PDM claims to implement PEP 582. However, if you look at what it implements, it is something completely different from the standard.

PDM’s file system structure

<root>
    __pypackages__
        3.10
            bottle
    myscript.py

PDM will scan for the __pypackages__ directory up to 5 folders above the “current” one.

PEP 582’s file system structure

<root>
    __pypackages__
        lib
            python3.10
                site-packages
                    bottle
    myscript.py

PEP 582 says that the __pypackages__ directory should be next to the script being executed, and there’s no discovery logic “above” the script.

How did this happen?

PDM implemented a draft PEP. Draft PEPs are not final, and are subject to changes. However, PDM cannot evolve with the PEP since that means frequent breakages to the user experience as the standard evolves.

This leads to a situation where PDM is advertising implementing a (draft) PEP, while not implementing that PEP since the draft has evolved.

Why does this matter?

Well, outside of the issues with implementing draft proposals in workflow tooling, I think this is reflective of the issues with the competitive nature of the Python packaging ecosystem’s workflow tooling space.

I’m willing to trust that PDM’s authors are well intentioned and didn’t intentionally aim to end up with “false advertising” in the first feature the project lists in the README.

Besides, I only took a closer look at this because I was talking to one of PEP 582’s authors recently, and LWN¹ linked to someone on the internet was claiming that PDM is a solution to Python packaging.