Update vendored packages for 22.3

[pradyunsg]

Toward #11486

[pradyunsg]

@pfmoore What's your git autocrlf configuration?

[pfmoore]

The default. Which, looking at it, is true. In general, everything I do, I try to use the defaults, because that way I won't forget 🙂

[pradyunsg]

OK, my guess is that it's likely what's making things break for you.

https://stackoverflow.com/questions/2825428/why-should-i-use-core-autocrlf-true-in-git

I'll try to grab a Windows VM and do stuff in it to investigate.

[pfmoore]

BTW, my main problem here is mostly that I don't really understand any of the machinery involved in the vendoring (which I believe is largely your rewrite of the previous invoke-based stuff, that I also didn't understand 🙂) And I've never really felt comfortable with git's handling of line endings, I just stumble through mostly living with the occasional weirdness. So while I can point out where things don't work on Windows, I'm pretty lost trying to fix stuff. I am happy to try out suggestions, if you need me to check stuff, though.

One thought - is it possible to configure the pip repo somehow so it's not reliant on what the developer's global settings are? Something like .gitattributes? Of course, then we'd get problems when people create new files on Windows which default to CRLF...

my guess is that it's likely what's making things break for you.

That's my guess, too. I remember the old patch utility used to go berserk when fed patches with CRLF in them. I didn't think git would have the same issue, as in general git seems less overtly hostile to Windows than the older tools, but maybe it does.

Although to be fair, the underlying issue is that the patch no longer applies. That's legitimate. There are 2 things that need consideration at that point:

1. How to we re-create the patch? The certifi patch hits this, as while it's easy enough to mechanically work out what the equivalent change is, I'm pretty sure just doing so is broken (there's a certifi issue where the maintainer expresses frustration at importlib.resources, and I can't say I disagree...)
2. What's a platform-agnostic way of rebuilding the patch? That's where CRLF issues and the whole "stage, change, make a diff, and discard" workflow is hitting me. Creating patches has always been a Windows-hostile activity, it seems to me (some of which is simply the fact that diff/git diff don't have an -o option, resulting in all sorts of flaky behaviour as a result of Windows' redirection mechanisms).

[pradyunsg]

Hmm... Digging into this, we've skipped quite a few setuptools upgrades: #9170

Which... is bad?

[pfmoore]

I believe it's because we only use pkg_resources and there's some problem with later versions (maye that's what #11501 relates to?)

[pradyunsg]

There are many fixes in newer pkg_resources (eg: around the packaging Version handling: #9250).

[pradyunsg]

There's more to do here.

[pfmoore]

The 22.3 release is planned for this weekend. I'm inclined at this point to release with the vendoring upgrades that have already been merged, and leave any outstanding ones for 23.0. The only one I am hesitant about is the certifi upgrade, as that includes certificate updates which are more important.

[pradyunsg]

I say let's get certifi in, and we can update the rest in the next release (bugfix or next major version -- whichever the RM is comfortable with). :)

[pfmoore]

It'll be 23.0 as vendoring updates don't count as emergency bugfixes IMO :-)

[pradyunsg]

Closing this out. Things we missed in this round can get picked up in the next one.