frostming

UX issues are the least important; it's just a matter of minutes for AI to improve, but you need to report it on GitHub.

The "unsafe version" is an unreasonable accusation. Do people really believe in semantic versioning—that not bumping the major version means it's safe? It also creates hard-to-resolve compatibility problems, causing more issues than it solves. Not capping dependency versions has basically become the consensus.

A Casual Discussion on L4 Load Balancing - by @laixintao(in Chinese)

https://www.kawabangga.com/posts/5301

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.

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.

Thanks for the kind words on PDM. At time of creating PDM I don't want it to be similar with any other package mangers, so I chose PEP 582, and I thought I can play more new stuff on it.

But as PDM becomes mature, it is acknowleged by the Python packaging people, I also work hard to make PDM fit more people's workflow, fortunately, it has a strong plugin system. You can add virtualenv support(pdm-venv), publish command(pdm-publish) and more. In the future, I would like to see it can eventually push the iteration of PEP 582 and make it finalized.

In PDM, add command supports a `--unconstrained` option to relax the version constraints to find a solution. You don't need to edit the file manually.

PDM author here, if anyone want to know the advantage of __pypackages__ over virtualenv-based tools(venv, virtualenv, poetry, pipenv), here it is: The fact that virtualenvs come with a cloned(or symlinked) interpreter makes it vulnerable when users want to upgrade the host interpreter in-place unless you keep all the old installations in your system, which is what pyenv is doing. You can imagine how many interpreters, including virtualenv-embedded ones are on your machine.

You can regard __pypackages__ as a virtualenv WITHOUT the interpreter, it can easily work with any python interpreter you choose as long as it has the same major.minor version as the packages folder.

> So careful, far from stable.

True, bugs can't be exposed by a few users. People have vastly different environment setup for their Python development. System python, in-venv, pyenv, asdf, homebrew, etc. So I post it here to seek for help testing.

The sematic versioning may be a bit misleading, it is just because there was a big breaking change to support PEP 621, and I marked it as "Alpha" stage.

As I wrote in the post, you cannot make two tools isolated in their own environment work together(work together meaning one needs to import from the other). The only way to make it is to install one tool in the global site-packages and create the other virtualenvs with --system-sitepackages and this flag is off by default.

__pypackages__ also has a bin/ directory and you can run the console_scripts with pdm run my_bin or by absolute path: /path/to/__pypackages__/3.8/bin/my_bin

Thanks for giving a look and leaving so many reactions. This project was originally built to experiment on some new PEPs on Python packaging and it turned out working well.

1. What does PEP 582 differ from virtualenv, it is just another "virutualenv" The biggest difference, as you can see, is __pypackages__ doesn't carry an interpreter with it. This way the packages remain available even the base interpreter gets removed. 2. I prefer Poetry/virtualenvwrapper/Pipenv It is fine. If you feel comfortable with the current solution you are using, stick with it. I am not persuading that PDM is a better tool than those. Any of the said tools does a great job solving its own problems. PDM, IMO, does good in following aspects:

- Plugin system, people can enhance the functionalities easily with plugins - Windows support, PDM has completion support for PowerShell out of the box. Other CLI features also work as good as *nix on Windows.