My summary: PEP 582 specifies a directory named __pypackages__ that works like node_modules for nodejs: the interpreter prefers to import from any __pypackages__ in any directory ancestor before checking user home or system-wide packages.
So, PDM is a package manager that much more closely follows the npm model than previous python package managers that use virtual environments (eg pipenv, poetry) or just install to the system (eg pip).
If I could give feedback to the authors, I’d remind them that very few programmers memorize the meanings of PEP numbers, so it’s much more helpful to discuss the benefits of your software than what PEPs it respects.
In addition, PEP 582 is still listed as a “Draft” (not Final, not even Accepted) from 2018. The listed motivation is that activating a virtual-environment is difficult and confusing (which is true) but I feel like there’s easier solutions to that problem:
direnv makes it easy to automatically activate a venv when you enter some directory in your shell and deactivate the venv when you leave it. It’s also able to set/unset variables, deal with Go/Ruby stuff, etc.
While I understand what it’s trying to solve, npm has its own disadvantages, like a huge hidden directory for every tiny project I clone and try. Also, a long install time, even when you have all the packages in a nearby directory.
In my ideal world, packages would be global by default, but then whenever there is a deviation from the package.lock, the user gets the choice to upgrade, or have the specific package installed locally.
Python ought to adopt a package scheme like
such that multiple versions can be installed at the same time, and such that if a program doesn’t request a specific version of a package, then it will get the newest (or the one that is configured as the default version).