Towards release 2.0

[frostming]

Planned changes in version 2.0

• PEP 665 support Rejected
• Switch the UI framework to rich, drop click. Fix(#677): Replace halo, click, and termcolor with rich. #1066 Feature: Replace halo, click, and termcolor with rich #1091
• Remove support of legacy pyproject.toml format: feat: Remove the compatible support for pdm legacy metadata #1157
• Drop the dependency of pip Use unearth as the backend to find and download packages #1096
• Decouple PDM from any build backend, making it a pure fronend
• Use XDG dirs for config #1150
• Associate dependency with source #593
• Restructure the documentation about PEP 621 metadata, tool settings and backend settings
• (Possible) Dependencies get overriden when there are multiple versions of different markers #46
  Experiment on sub-resolvers to address the multi specifications for one dependency

It won't happen shortly, at least before PEP 665's finalization.

See the Release 2.0 milestone for the latest progress.

[pawamoy]

Care to elaborate on the reasons that make you want to switch to Rich 🙂 (I personnally don't like Click but didn't think Rich would offer similar CLI features)? Isn't it going to be a big refactor?

[frostming]

Care to elaborate on the reasons that make you want to switch to Rich 🙂 (I personnally don't like Click but didn't think Rich would offer similar CLI features)? Isn't it going to be a big refactor?

For many reasons:

1. The API to colorize output is annoying when nested, and it always resets all styles when the color ends: yellow(f"Hello, {red('World')}. Python") produces Python uncolored. As a comparison, rich supports color themes
2. PDM uses a patched version of halo to provide parallel spinners because the upstream project is inactive and the PR is not merged for a long time.
3. Even so, the parallel spinners could have a race condition in rare cases
4. The column display implementation is very simple and the line will break when exceeding the max terminal width.
5. All these are provided by Rich out of the box, strong and well tested, the author of Rich engages full-time OSS so it is well-maintained.
6. The only thing that stops me from adopting rich is it adds a number of dependencies. The size of pygments alone is 4MB. If only Rich were splitted into smaller packages.
7. The refactor can be controlled under an accepted scope since click is only used to offer terminal output features. The CLI parsing is done by argparse

[pawamoy]

I see, thanks! Ah, the constant battle of using libraries while reducing dependencies ^^

[harkue]

look forward to this feature:

New in version 1.12.0

[tool.pdm.overrides]
asgiref = "3.2.10"

[gitpushdashf]

Regarding Click/Argparse, what do you think about Typer? https://github.com/tiangolo/typer

It does use Click under the hood, which makes testing much simpler.

[frostming]

@gitpushdashf command-line parsing is not the problem, argparse works very well. But the terminal UI part needs to improve.

[jessekrubin]

FWIW: @gitpushdashf I converted a large many nested-commands cli app from argparse to typer and it is okay; in my experience typer's windows support was meh (which is a dealbreaker imo). personally I recommend click over typer, and argparse over most things unless you need type-annotation support (where typer and click are both good).

EDIT: The overrides feature also looks super nice

[daylinmorgan]

@frostming

Regarding: "Switch the UI framework to rich, drop click."

I've managed to accomplish this and replace all uses of click in the actual pdm code itself. Additionally I've dropped the dependency on halo and termcolor, and used rich for prompts and table generation.

Currently click is still a testing dependency but I don't think this is strictly necessary with some minor changes to either the tests or the argument parsing by pdm. Currently, the only failing tests are due to CliRunner forcing the output to 80 columns.

To begin with I wanted to make only minimal changes. So there is still usage of termui.<color> throughout but I can replace all these with the appropriate inline markup supported by rich. I.e. f"{termui.blue('PDM')}, python development master" can be replaced with f"[blue]PDM[/], python development master". I think the inline style of strings used by rich is much more readable.

If you are interested in merging this before a 2.0 release I can submit a PR to hash out some of the finer implementation details. If you want to make use of color themes it would be good to know before replacing all of the termui.<color> functions.

With respect to the pygments dependency concern we could take the approach of pip and vendor it removing the syntax highlighting and markdown code.

[frostming]

@daylinmorgan Thanks for that, it is awesome. I also prefer to use the rich inline markup for colors. Looking forward to your PR.

[frostming]

For those who are interested I am already working on a standalone package to replace pip's PackageFinder. After that is done we can start the process of v2.0

[frostming]

Hi, an alpha prerelease has been created: 2.0.0a1. Welcome to install and test the new features!

[smokeythemonkey]

@frostming

curl -sSL https://raw.githubusercontent.com/pdm-project/pdm/main/install-pdm.py | python3 - --prerelease
This installs 1.15.4 instead of current pre-release.

OS: Pop!_OS 22.04

reinstalled pdm with pipx, this works as expected

should I make an issue for this?

[frostming]

@smokeythemonkey Thanks, will fix it soon, you can anyway run
curl -sSL https://raw.githubusercontent.com/pdm-project/pdm/main/install-pdm.py | python3 - -v 2.0.0b2

[SystemTheory]

In my WSL Debian I first installed pdm via pipx and then again via the curl command shown above. This raises a few questions concerning management of the pdm version in the following context.

Now pdm exists in two directories under the .local folder as shown below.

/home/joe/.local
$ echo; tree share -L 1; echo; tree pipx/venvs -L 1

share
├── nano
└── pdm

pipx/venvs
├── black
├── flake8
└── pdm

/home/joe/.local
$ pipx list
venvs are in /home/joe/.local/pipx/venvs
apps are exposed on your $PATH at /home/joe/.local/bin
package black 22.6.0, installed using Python 3.10.4
- black
- blackd
package flake8 4.0.1, installed using Python 3.10.4
- flake8
package pdm 1.15.4, installed using Python 3.10.4
- pdm (symlink missing or pointing to unexpected location)

/home/joe/.local/bin
$ tree -L 1
.
├── black -> /home/joe/.local/pipx/venvs/black/bin/black
├── blackd -> /home/joe/.local/pipx/venvs/black/bin/blackd
├── flake8 -> /home/joe/.local/pipx/venvs/flake8/bin/flake8
└── pdm -> /home/joe/.local/share/pdm/venv/bin/pdm

Now pipx reports the pdm symlink points to unexpected location. So I can't uninstall pdm 1.15.4 using "pipx uninstall pdm".

1. How do I uninstall pdm 1.15.4 so it does not show in the pipx list?

2. How would a user install pdm 2.0 via pipx command instead of curl? In that case does Git LFS have to be separately installed on the system?

3. How would a user uninstall pdm 2.0 files from the share/pdm directory?

I hope this is the appropriate place to ask these questions. I did not see clarification anywhere else in the documentation.

[frostming]

@SystemTheory

How do I uninstall pdm 1.15.4 so it does not show in the pipx list?

Just remove the ~/.local/pipx/venvs/pdm folder

How would a user install pdm 2.0 via pipx command instead of curl? In that case does Git LFS have to be separately installed on the system?

pipx install/upgrade --pip-args=--pre pdm

Git LFS doesn't need to be installed.

How would a user uninstall pdm 2.0 files from the share/pdm directory?

curl -sSL https://raw.githubusercontent.com/pdm-project/pdm/main/install-pdm.py | python3 - --remove

[frostming]

The 2.0 release is scheduled for this Friday(7/15) and this issue will be closed. Bug reports are better before then than after. Thanks all for testing!

[frostming]

Closed by https://github.com/pdm-project/pdm/releases/tag/2.0.0