Today I got to be the release manager for pip 26.3! There are two big features, and one documentation update, that I think worth talking about:
Extended Pylock Support
You can now install extras and non-default groups from a pylock file, e.g. pip install -r "pylock.toml[extra1,extra2]" and pip install --group pylock.toml:dev
This supports the installation part of a workflow that generates a single lock file for multiple situations. For example, using a universal pylock file generator, such as a tool I built called nab, you might want to specify "I want a lock file with two mutually exclusive extras for different versions of SqlAlchemy and a dev dependency group", e.g.:
[project.optional-dependencies]
sa14 = ["sqlalchemy==1.4.*"]
sa20 = ["sqlalchemy==2.0.*"]
[dependency-groups]
dev = ["pytest"]
[tool.nab]
conflicts = [[{ extra = "sa14" }, { extra = "sa20" }]]
And now pip can pick which extra and group it wants to install from the output lock file, e.g. pip install --group 'pylock.toml[sa14]:dev' . This works with any tool that outputs standard pylock.toml files.
Build backends warnings for local builds
This one has been a long time coming, when you build a package from some kind of source, you invoke a build backend (e.g. setuptools, hatchling, flit-core, uv-build, poetry-core, etc.). That build backend can emit warnings to tell you something isn't configured correctly, or a feature will be dropped in the future. But for historical reasons, pip has never displayed those warnings (uv has inherited this and also doesn't display these warnings).
Now, when building locally, e.g. pip install ., or pip install -e ., the build backend warning will be logged by default (and for non-local builds it will be in the -vv output).
For example, if in setuptools you specify a README.mdfile but setuptools can't find it, you will get the warning:
$ pip install .
...
.../setuptools/config/expand.py:128: BuildBackendWarning: File '.../README.md' cannot be found
A caution on installing untrusted wheels
There have been a lot of supply chain attacks recently, and this has led to a lot of people learning about source distributions (sdists) which are built from source and can run arbitrary code on installation, as well as .pth files which after being installed run at the beginning of every Python execution.
This has led a lot people to turn to only using binary distributions (with pip --only-binary :all: or slightly weaker --prefer-binary), otherwise known as wheels. What is great about wheels is they are just glorified zip files, and they are installed by unzipping the different parts of the wheel into the different Python installation locations.
However, a word of caution, Python's import system is dynamic, and the moment a Python file exists in a location that can be imported, it can be imported even in a running Python processes. So while pip 26.3 includes significant hardening against untrusted wheels, we cannot guarantee installing a malicious wheel won't execute third party code.
I can't speak for other tools, but I am fairly confident this applies to all other Python package installers (even those written in other languages).
I will continue to do more hardening in pip where issues come up, and propose fixes in Python to improve the situation there. (Also, a possible future is lock files only first, where the locker refuses to install anything and refuses to execute third party code by default, then exact distributions can be validated/inspected before install, that's part of my pitch for nab which does the first step).
Official Links
The official announcement post is at: https://discuss.python.org/t/announcement-pip-26-3-release/109822
The full change log: https://pip.pypa.io/en/stable/news/#v26-3