1. 18

  2. 11

    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.

    1. 9

      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:

      1. Just don’t activate virtualenvs, and don’t teach people that it’s a thing they’re expected to do. Instead of activating a virtualenv, you can just run the wrapper scripts in venv/bin/ directly and they’ll automatically set everything up before invoking the wrapped script.
      2. A lot of the complexity of activation comes from the design decision to reconfigure the current shell environment, and to be able to deconfigure it again later. Unix natively supports (and MS-DOS/Windows copied) the idea of a modified execution environment - if the activation script just set the right environment variables and executed $SHELL (or the equivalent on Windows) then it would be an ordinary command (not an unfamiliar source command), and it would be consistent across platforms instead of being weirdly different depending on the shell you’re using.
      1. 3

        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.

      2. 2

        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.

      3. 3

        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).