What's new in pip 24.3

[trail sluice]

I think the "greater than" sign is this snippet is wrong:

Your packaging setup is so old that it requires a version of setuptools (>64)

Presumably should be "<64" or "<65"

[gray shadow]

ah yes, thank you for catching that

also, I know that "You can also read my write-up on pip 24.2 which goes into more detail" is missing a link. I will add that as well.

[trail sluice]

For the line:

add a pyproject.toml file that declares your package’s build system to be setuptools

I would personally give an actual snippet (or link to somewhere that does):

[build-system]
requires = ["setuptools >= 65"]
build-backend = "setuptools.build_meta"

Reading it as user with little knowledge of Python packaging it's a bit hard to understand

[gray shadow]

I didn't want to repeat myself heavily, but yeah. I can do that

I'll add an inline note to go to the deprecation issue as I don't want to maintain advice over many locations.

[gray shadow]

It's awful to explain any of this to Python newbies. It's virtually impossible to understand without knowing a bit to how it all works under the hood.

You essentially need to paper over all of the complexity while getting across that you need this special file for "reasons".

(just trust me, please)

I tried to strike a balance between being informative and offering clear, actionable advice in the issue, but I realize that more could be done to make it stupidly simple to address even if you have no interest in learning how this works.

[trail sluice]

Yeah, if someone was designing this from a user experience point of view the installer should be able to assume an implicit pyproject.toml with an implicit backend, and not worry the user about it until they get to the point where they actually care about dependencies and build configuration

[gray shadow]

At a certain point, I think pip will essentially be defaulting to that once the legacy flows are gone. The transition is miserable, though.

[trail sluice]

Yeah, I think uv might already be doing that

[gray shadow]

There would be a lot of "oh that's bad design" issues that could be easily fixed if we started from scratch.

That ain't us though. That's uv and friends.

Anyway, I'm going to leave this up for feedback for a few more hours at least, and then I'll just share it around afterwards. Worst case is that another maintainer of another tool messages me saying that I got something wrong

Thanks for taking a look!

[trail sluice]

I'm not sure this footnote makes sense:

For example, translate_toolkit-1.9.0_pinterest3-py27-none-any.whl could be using _ as a separator between the version and build tag (although, it is ambiguous as pinterest3 is not a valid build tag)

If pintrest3 is not a valid build tag then it's not ambiguous?

[gray shadow]

I guess not. I should've said the intention was ambiguous.

I'll reread this once I do some other work and have a clearer head.

[cosmic cave]

thanks for the writeup! some minor nits:

"released in the same day" -> "released on the same day" ?

"And yes, I know this post is awfully late." No need to apologise 🙂

"as of writing" -> "as of this writing" ?

the first pip install example with the deprecation, it would be more readable if you inserted some line breaks so there's not a very long horizontal scroll, especially for mobile

the second isn't as long but would also benefit

"Pip simply won’t be running it directly anymore" -> "pip simply won’t be running it directly anymore" , normally pip is lowercase even at the start of a sentence.

"Show lengthy error"
try replacing console with pytb for marking up the traceback, you get better syntax highlighting

"Show another lengthy error"
try pytb here, because the important bit is another trackback

[gray shadow]

Unfortunately Hugo's syntax highlighting doesn't seem to support pytb.

I incorporated all of your other feedback though. I opted to trim the traceback as no one needs that much detail.