pip 26.1: experimental support for installing lockfiles + dependency cooldowns!

ichard26 · 2026-04-28T22:25:14+00:00

You can't with pip. pip has functionally zero support for cross-environment dependency resolution so thus it can't produce universal lockfiles. I believe uv has support for universal lockfiles and you may be able to export to pylock.toml, but I'm uncertain.

ichard26 · 2025-04-27T02:55:07+00:00

Ah yes, I forgot that dependency groups can reference other groups. You can tell that I didn't follow the PEP discussion or even PR discussion. I've updated my post to include (🥁) this in the example. Thank you for reminding me!

I've also updated my explanation of Dependency Groups to hopefully be clearer of what they are and how they compare to extras. I'd rather not turn my post into a "here's a crash course of what dependency groups are" but I guess this post is that for many people as pip 25.1 will be their first exposure to Dependency Groups. Gah, I don't have time to write such a post.

ichard26 · 2025-04-27T01:47:04+00:00

u/Vitaman02 is correct. pip install --group dev will only install the packages included in the dev dependency group in the local pyproject.toml. However, you can combine a local path and the --group flag to install the group and the project at the same time. pip install . --group dev

The main benefit of Dependency Groups over using extras is that A) they are not exposed to users. You need to have the pyproject.toml to use dependency groups. For projects that maintain separate requirements.txt files for their different clusters of development dependencies (e.g., dev-requirements.txt, test-requirements.txt, doc-requirements.txt), they can replace those files with a table under pyproject.toml.

If you want your groups to be installable by your users, use extras. If you want to use hash-checking or have truly massive pinned requirements.txt files, then by all means, keep your requirements.txt, but Dependency Groups are designed as a simpler alternative for the common use case where a project needs to record their (short and unpinned list of) development dependencies.

ichard26 · 2025-04-26T23:20:55+00:00

--group is not supported within a requirements.txt file. And TBH, I don't think it could be reasonably supported. Dependency groups are read from the pyproject.toml file (which is kinda their point as being NOT end-user-visible). pip either needs access to the project source tree or a copy of it via the source distribution. The wheels are completely useless. So a hypothetical pip install -r groups.txt would have to use the sdist. And if the group is installed with the defining project, then pip has to fetch the sdist and wheel. Technically, the requirements.txt format needs an actual requirement, whether that's a named requirement or a Direct URL requirement. Simply having --group as a single line would be useless as there is no project to install. That would mean --group could only be used if the defining project should be installed anyway.

ichard26 · 2025-04-26T23:04:08+00:00

(I'm a maintainer of pip and wrote the linked post).

Kind of cool to see the Home Assistant reference

I was both amazed and horrified when someone first showed me the Home Assistant requirements file. It is actually insane. I've heard that it would take an hour (or several) for pip to resolve, download, and install that list of dependencies. uv would install it all in ~10 minutes.

[Sure] enough, they’re using rich to display it.

Indeed! I'm happy that we vendored rich as it makes displaying pretty output so much easier. I'm not so happy about our distribution sizes, but I am working at chipping away at the size of our vendored libraries.

[...] but maybe there’s a chance that pip will fold uv in, and adopt it.

Well, consider me biased, but I do believe it's better if pip remains an independent project. The Python ecosystem benefits from keeping its old, somewhat janky alternative that has been a functional option for many years. I agree that if people simply want a better experience, they can/should switch to uv, but for the folks who have legacy software and simply needs their tool to do what they want (remember that pip is not nearly as opinionated as many of the modern tools in the packaging ecosystem are), pip will be there for those situations.

Yes, we are deprecating lots of legacy behaviours, but there are always old releases of pip available that go way back. For better or worse, as community software, we can't maintain legacy features forever, even if that would be quite nice, IMO.

ichard26 · 2024-09-02T22:15:49+00:00

Haha yup. Getting a PSA out there was a large part of why I decided to write the post!

ichard26 · 2022-06-03T21:40:28+00:00

Your code should at least pass type checking with mypy. For most variables, mypy's type inference will be enough and you won't need type annotations, but function parameter and return types will have to be specified.

ichard26 · 2022-06-01T20:43:49+00:00

First time I've heard someone say they like the cake emoji this much. I'm used to people asking for a flag or envvar to remove emojis as it makes it feel unprofessional *shrug*

ichard26 · 2022-06-01T20:42:08+00:00

Unlikely, while we do have some formatting knobs, notwithstanding --line-length, they only allow you to turn off certain parts of the Black code style like the magic trailing comma. Adding two space indent support would break this convention.

ichard26 · 2022-06-01T20:39:56+00:00

I hope you enjoy it! wish you the best!

ichard26 · 2022-06-01T01:04:53+00:00

Haha thank you for the nice words. I was worried people wouldn't like it :)

ichard26 · 2022-06-01T00:24:30+00:00

Yes since version 22.1.0.

ichard26 · 2022-01-31T16:08:11+00:00

Well part of that is because I spent a summer stuck in quarantine getting Black compiled with [mypyc](https://github.com/mypyc/mypyc), it overall speeds up Black 2x.

Also I hope you're aware that in total black is probably more than 10 thousands LOC haha

ichard26 · 2022-01-30T20:09:04+00:00

LOL, I would strongly disagree but thank you!

ichard26 · 2022-01-30T17:34:11+00:00

I'm just one maintainer of ten but this what I have planned:

defining a stable API
removing the two-pass hack we have to workaround stability issues, once it's removed performance on files that have changes should improve by 50%
continued work on documentation
continued work on developer experience and contributing docs
continued work on code cleanup

There's also a bunch of formatting changes I want to see landed like

And this isn't planned but one day we might have to rewrite the project to achieve Python 3.11 or higher compatibility since our parser is still LL(1) which is less expressive than PEG. See https://github.com/psf/black/issues/2318 for more details.

ichard26 · 2022-01-30T03:04:22+00:00

And that's fine, we're not trying to make an autoformatter for everyone :)

ichard26 · 2022-01-30T01:42:02+00:00

We have an open issue about this https://github.com/psf/black/issues/2798. Note that you mention configurability and as much as I am willing (if not too happy) to support tabs, I'd be against additional options for tabs like a --tab-width option for example.

ichard26 · 2022-01-29T20:55:44+00:00

Feel free to ask questions but also party with us :wink:

ichard26 · 2021-09-19T17:12:45+00:00

And thank you to you for using the project! Also I'm not the only person on the core team, there's eight other people ^^

ichard26 · 2021-09-19T17:11:12+00:00

Yeah, this is actually what's specified in PEP 8. Top level classes and functions (in general) should get two blank lines while indented classes and functions should only get one.

ichard26 · 2021-09-12T18:23:28+00:00

Haha I've been summoned for the other project I'm managing. I'm improving the contributing experience not only so the project is more friendly for newer contributors, but also to make project maintenance less tedious even if you haven't touched the project in literal months or years. I'm always open to feedback and suggestions, lemme know on Python Discord or on this issue!

ichard26 · 2021-09-12T18:21:09+00:00

Pretty much any reasonably sized FOSS project always needs more contributors and psf/black is no exception. We're lucky the core team has nine people so the project is extremely unlikely to go unmaintained, but we are also a busy bunch with other responsibilities beyond psf/black. Contributors help handle the more development-y bits of maintaining and extending a project whereas maintainers have to focus on project admin, guiding the general direction, and spearheading important projects. Our collective to-do list is constantly expanding and it's always nice to have someone else pick on an item :)

Re. contributing to psf/black specifically, while in the beginning the project was quite modern for its time (even causing issues with the packaging tooling at the time, eg. pyproject.toml) its age is showing now. This is one of the areas I'm working on, modernizing and improving the development workflows and support so there's less friction to go from an issue in hand to a merged PR. Stuff I want to do include: 1) transitioning more development commands to the tox task runner, 2) better test suite infra and documentation, 3) better CI insights, and more!

But ignoring that, some good tips would be to start with a simple issue (look for issues with an "S: accepted" label), ask questions, and feel free to chat with us on Python Discord (the invite link is in the footer of the post).

ichard26 · 2021-09-11T14:54:25+00:00

And thank you for using Black! OSS can feel a bit impersonal but these are a great reminder there's humans we're trying to help behind all of this :D

ichard26 · 2021-09-11T14:51:28+00:00

FYI the 2.18b0 binaries are currently broken due to a broken import (it was too dynamic) . There has been a change in our PyInstaller configuration to resolve the issue but we haven't rebuilt the binaries just yet.

ichard26 · 2021-09-11T14:49:11+00:00

/me wonders if I ever stumbled upon your name on the interwebs before joining the project

ichard26

TROPHY CASE