New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release 24.1 #12613
Comments
Do we expect the If the |
Yes. If no one else has bandwidth, I'd be willing to be the RM for this one. I expect we're going to have a beta period, to get some user feedback on the legacy version removal situation (thank you to @sbidoul for doing most of the work on #12300!) and to also make follow up fixes we'd likely need. |
OK, if we're putting the packaging upgrade in, I'll leave it with you. I'm happy to help where I can, so feel free to ping me if you think I can help. I'll try to find some time to review @sbidoul's PR in the next day or two. |
Regarding a beta release, I'm not entirely convinced it will help (my instinct says not enough people will notice/care), but that's up to the RM, of course ;) |
I would test a beta and I'm sure @potiuk would as well, I would also try to spread the word on social media as much as possible. However, I will say, the one time that pip recently had a beta it didn't get much exposure. On release though, I will again mention that resolving is not sound #12317 and I have a fix here if anyone has time to provide any more feed back sarugaku/resolvelib#144 Also this PR seems fairly small and would be a great performance news item for Pip #12453 (and more complex but would be a big UX improvement news item, would be #12388 and #12404 if they are considered close to ready) |
A summary on macos runners which are currently blocking CI runs:
So it needs to be decided whether to keep running x86 as well as ARM (#12593) or just stick with "latest" which is now ARM (#12617). And someone either needs to fix this test (I don't know what the issue is and have no way to reproduce locally) or whether to exclude Python 3.8 and 3.9 from MacOS ARM. |
I'd also like to nominate #12657 for 24.1, it's very simple, and I've measured a significant performance improvement on large number of packages to resolve, and even a slight perfornance improvement on small number of packages to resolve. |
Oh wow, this month has flown by. I'm catching up on my RM duties now. 😅 |
I did report small issue while ago: useless warnings in "pip list --outdated --verbose". |
I know this was asked by Paul above and answered, but is the Do you expect the 24.1 release before the Python 3.13 beta 1? |
I posted a status update on the PR: #12300 (comment) |
As it seems there's very likely to be a beta that hopefully will get some wide coverage, I would like to make the case for pip maintainers to be a little bit more agressive merging approved open PRs that are in a good state: I appreciate pip is under resourced and generally conservative in accepting PRs, but having a long open approved unmerged PR can be a little demoralizing to potential future contributors. |
I've moved a few of those onto the 24.1 milestone, where I think they are clear-cut ones that should be merged. The others I think might need a little more consideration than I have time for right now. (I'm not arguing against them, though). |
OK, we're almost all set for 24.1b1 to be released today. I have one outstanding PR to merge and then will cut a release after grabbing lunch today. |
https://pypi.org/project/pip/24.1b1/ is up. I'm not updating get-pip.py or filing a PR to CPython with an updated wheel for this. |
Are you going to post an announcement on discuss.python.org? It might be a good way to attract a few more beta testers. |
Yep, I plan to do that along with a blog post that serves as a call for beta testing. That'll all have to be after my work day today though, since pip maintainance isn't a part of my day job anymore. |
FYI. I can confirm that the most complex case with installation and eager upgrade for latest airflow version with 24.1b1 works fine. Not super comprehensive, but passes as "smoke test" IMHO |
@potiuk Is it meaningfully quicker? :) |
Not too scientific but looks like ~ 15% (~550 seconds -> ~470 seconds) - on a very small sample. |
Roughly what is that running? Anything that gets stuck doing a bit of backtracking should see more significant performance gains. But if the versions here are all tightly constrained that is about in line with what I would expect. |
Roughly this:
|
Some more detailed stats on ARM as well (likely a bit more time needed to build some wheels): PIP 24.0: Total time: ~590 sec
24.1b1: Total time: ~550 sec
So ~ 40s of collection/downloading shaved. |
That seems reasonable, pip hasn't got any faster at downloading, so the IO overhead will be the same, it's the collecting part that got faster. There is an open PR for pip to start downloading in parallel. Interesting to see if it makes a noticeable difference in a future release. |
I will keep an eye. Same step with #46 56.23 Resolved 631 packages in 48.60s I am not sure when package building happens - but I assume it's both downloading and building that is heavily parallelised as well. and yeah, would be be cool to see those improvements in |
I think I found an issue with Consider these requirements: # requirements.txt
sqlalchemy==1.4.* Create a virtualenv that uses pip 24.1b1:
Install the requirements:
and it fails
Full output
|
@edgarrmondragon could you file an issue for this (and run the pip install with |
Will do! (at some point later today 😅 ) |
I strongly suspect that error is related to hyphen/underscore normalization in extra names (mariadb-connector vs mariadb_connector) and pkg_resources vs packaging/pip having inconsistent normalization logic. I'd guess packaging upgrade may have touched extra normalization logic and I've seen inconsistencies across pkg_resources normalization/pip in past elsewhere as well with extras having hyphens. edit: The last time I looked into this error my initial thought was fix seems best placed in pkg_resources itself and it doing lookups in normalized aware manner. |
Running your steps of editable installing 24.0: ~208 s So an absolute time not too far out from your own testing, and a ~25% improvement in resolving and building metadata from sdists for this set of requirements (note the building itself won't have improved). Interestingly I see a much bigger performance improvement with I'm going to make a follow up issue to look at the final install step, as that is taking a surprising amount of time, but that's for future versions of pip. |
It's April already.
Any @pypa/pip-committers up to take the RM hat this month?
The text was updated successfully, but these errors were encountered: