Update vendored dependencies (requests, certifi, tomli)

[sbidoul]

No description provided.

[sbidoul]

Here I manually limited tomli to 2.3.1 (see also #13756)

[notatallshaw]

I don't think we need to vendor in rich's vendoring of old Unicode databases, I skimmed over the issue a few weeks ago but didn't have time to verify.

[ichard26]

I'd much rather not upgrade rich than include whatever copy of some Unicode database rich has TBH.

[notatallshaw]

I'd much rather not upgrade rich than include whatever copy of some Unicode database rich has TBH.

I don't think that's tenable long term, I think we should do two things: Break out rich vendoring from this PR, and open an issue with rich to make sure it makes sense for us to just not vendor the full old unicode databases and that won't cause issues long term.

[ichard26]

Well, yeah. I just don't think it's worth pushing to include an update to rich for pip 26.1.

[pfmoore]

I agree with @ichard26 here. I’m increasingly frustrated with the amount of bloat we are bringing in with rich, largely for features we do not use or do not care about. Maybe the rich project would be amenable to making it possible to get some sort of “minimal” version that excluded the expensive dependencies and features that depended on them?

But in the short term I think delaying the update while we consider our options is reasonable.

[pradyunsg]

Maybe the rich project would be amenable to making it possible to get some sort of “minimal” version that excluded the expensive dependencies and features that depended on them?

When I'd brought this up a few years ago, Will had mentioned that he would be open to it; if the standards supported something along the lines of default extras (so that he could have a "core" and non-core stuff around it).

[pfmoore]

Will had mentioned that he would be open to it; if the standards supported something along the lines of default extras

Yeah, that proposal appears to have stalled...

[dstufft]

You can mimic that with a rich-core that has the minimal stuff and a rich that doesn't (and depends on rich-core), but I dunno how amenable he'd be to that.

[pfmoore]

You can mimic that with a rich-core that has the minimal stuff and a rich that doesn't

This is one of the alternative approaches that were suggested in the discussions around default extras. I don't think¹ there were that many good arguments against it beyond various forms of "I don't want to". Maybe rich will be another project that simply doesn't want to. It's worth asking, though.

Footnotes

1. I'd need to re-read the discussion to be sure, it's been a long time... ↩

[notatallshaw]

Well, yeah. I just don't think it's worth pushing to include an update to rich for pip 26.1.

Agreed, let's skip it for 26.1.

I'm increasingly frustrated with the amount of bloat we are bringing in with rich, largely for features we do not use or do not care about.

Two things I think we should be cognizant of: Rich is essentially a terminal rendering library, every rending engine-like tool I've followed (browsers, graphic drivers etc.) balloon in size over time as edge-case fixes and optimizations win out over disk savings. And commercial Textualize project is now defunct, so large scale refactors might be much less likely.

I'm not saying we shouldn't ask for changes, but I think bloat is a bit of an opinionated term, everything will have been added for a reason.

[pfmoore]

Agreed, sorry. It's bloat for us, not for rich. And that's at least in part because Python doesn't have good ways to only install parts of libraries that are needed (unless the library makes the effort to make that happen).

[sbidoul]

I've removed rich and pygments from this PR.