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.

Why is node doing bad things a justification for other package managers doing bad things?

I'm not following why storing project scoped things at the project level is a bad thing.

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.

Just made an account to say this. I am really impressed by your projects. I first found out about pdm after writing a small plugin for marko (which is amazing by the way) and checking out your github profile. I find what you write to be really well thought out and approachable.

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.

I have a lot of respect for the way you react to this comment, and how quickly you fixed the bug.

Thank you for working on such a useful project, and so seriously.

I immediately encountered a second different error, and I'll also take the time to craft a good bug report for it.

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.

How does PDM deals with binary python modules like foo.so that in turn depend on other binary libraries like mylib.so? This is what conda manager and conda environments are great for, covering the ground for all major platforms.