The big distinguisher of PDM is that it support PEP 582[0]. That means it works less like Pip and works more like NPM of the JS world. To quote PEP 582:
> This PEP proposes to add to Python a mechanism to automatically recognize a __pypackages__ directory and prefer importing packages installed in this location over user or global site-packages. This will avoid the steps to create, activate or deactivate "virtual environments". Python will use the __pypackages__ from the base directory of the script when present.
Thus, the idea of PDM is that it will create a directory, called `__pypackages__` in the root of your project and in that folder it'll populate all the dependencies for that project. Then, when you run scripts in the root folder of your project, your Python install will see that there's a `__pypackages__` folder and use that folder to look up dependencies.
This style of "dependencies inside the project directory" is similar to how npm of the Javascript ecosystem works, where it creates a `node_modules/` folder in the root of your project and fills that folder with the dependencies for your project. This style of dependency management is different from other package managers such as Poetry (Python), Pip (Python), go (Golang), and cargo (Rust), all of which instead have a sort of "secret folder acting as cache of dependencies at particular versions", a folder that's usually pretty hidden out of the way, in which the package manager automatically manages the acquisition, storage, and versioning/version resolution (Poetry, Go, Cargo, all do this but Pip does not).
That's a very fast and probably wrong rundown on what makes this package manager different from others.
I’ve long been of the opinion that pip and venv (and sometimes pyenv) is good enough. PEP 582 is a rare instance where a new packaging proposal makes sense right away when I read it and could beat pip and venv in simplicity.
It seems functionally similar to venv but has the benefit of standardizing the location of dependencies to __pypackages__/3.x/*. With venv the developer selects some arbitrarily named directory that is sometimes but not always .venv/*.
venv and PEP 582 seem to solve overlapping but slightly different problems. venv packages a python environment (interpreter and packages) without inherently tying it to a project (a project specific one might be embedded in a project directory, or a shared one might be used somewhere else, and you might even have multiple used for the same project, e.g., for different python versions or to validate against different versions of dependencies, etc.), while PEP 582 ties dependencies (possibly for multiple interpreter versions) to a project, but leaves supplying and identifying the right interpreter to use to some other system.
I like the "venv per script" approach. So it is like... you create a directory that contains main.py and foo.pdm or whatever its extension is, and then it grabs all the dependencies into that directory when you run a command and has a lock file and everything? I did not check out the website yet, that is why I am asking. If this is the case, then it is a win in my book.
Yes, PDM does some hacks to make it work with the familiar `python` executable. See the example at https://github.com/pdm-project/pdm/#quickstart. All you need is a fews lines to set up your shell.
Basically PDM supports project-specific python package installs. This is different from how python has traditionally worked where it has installed globally for the user running it. Why is this important? Because with virtual environments it's easy to forget to activate a virtual environment and run a pip install or upgrade and clobber your computer or server's python environment. It also avoids the confusing issue where someone updates their PATH variable while in a venv, but then its no longer there after exiting the virtual environment.
PDM also supports centralized package cache like [pnpm] while still keeping project's dependencies isolated.
> Also this will just pollute your source directories with generated directories and files that shouldn't be there.
I don't see why it is a problem, node.js also has node_modules in the project. And __pypackages__ is created with a .gitignore file so you won't commit it accidentally.
