search

pypa / pip

The Python package installer
https://pip.pypa.io/
MIT License
9.51k stars 3.02k forks source link

Release 24.3 #12941

Open pradyunsg opened 1 month ago

pradyunsg commented 1 month ago

Filing this eagerly, because I figure it can't hurt. :)

pradyunsg commented 1 month ago

I won't have bandwidth to take on this release cycle and also don't wanna be hoarding on the release manager responsibilities. 😉

pradyunsg commented 1 month ago

And, FYI: https://github.com/pypa/get-pip/pull/218#issuecomment-2310759449

notatallshaw commented 1 month ago

For anyone who is also a maintainer of resolvelib I'm waiting on a release (https://github.com/sarugaku/resolvelib/issues/159) to fix several known incorrect ResolutionImpossible errors.

And while I'm asking for things that affect pip but require other projects with overlapping maintainers: https://github.com/pypa/packaging/pull/794

sbidoul commented 1 month ago

I'm happy to take the RM hat for 24.3, unless anyone else wants to. I have very limited availability at the moment, so the release would be towards end October, mostly taking what is merged on main at that time.

pfmoore commented 1 month ago

If you'd prefer I can take it. My availability is also limited, but for me it's more unreliable, so it'll be a case of "you'll get the release when I have a free weekend". I'd also stick with just releasing what's on main - I'm happy to remind people of stuff on the 24.3 milestone, but I won't complete them myself.

Ping me if you'd rather I did it.

kotborealis commented 1 week ago

When will be 24.3 released? pip 24.2 still contains urllib3 1.26.18 which is affected by CVE-2024-37891 (GHSA-34jh-p97f-mpxf).

sbidoul commented 1 week ago

I'll have a look at what is in the 24.3 milestone soon.

Then I plan to release what is in main around October 20 or 27.

pradyunsg commented 1 week ago

@sbidoul I took the liberty of assigning this issue to you. 😅

notatallshaw commented 1 week ago

FYI, I've moved the issues which depended on a new resolvelib release and vendor to from milestone 24.3 to 25.0, as I reason here: https://github.com/sarugaku/resolvelib/issues/159#issuecomment-2404848946

notatallshaw commented 1 week ago

If 24.3 is the last version to support Python 3.8 I think it would be a big help, for a small number of users, if truststore released with https://github.com/sethmlarson/truststore/pull/157 and it was vendored by pip. Just on the intuition that old versions of MacOS might be using old versions of Python.

If at least pip 25.0 supports Python 3.8 I think it's less important.

potiuk commented 1 week ago

Comment from a side/user: agree with @notatallshaw. The worst that could happen is that users who are sticking with 3.8 will not be able to run 25.*. Which might incentivise them to upgrade Python.

I think it might be worthwile to add a warning - if someone uses < 25.* and they use Python 3.8, the "upgrade available" message could include the warning about using EOL Python and telling the user to migrate to higher version of Python as well. That would be a win-win for the ecosystem - encouraging people who are not even aware that Python 3.8 is already EOL.

I think it would also be great to agree general policy on which Python versions pip supports in general - and make it a "standard" approach for future migrations as well. This helped a lot in Airflow - we have now policies agreed on that and rather than discussing it, we jus follow the rule we agreed before (or if we want to change the rule, it's clear we need to start a discussion on it including justification for change).

potiuk commented 1 week ago

BTW. My proposal above means adding support / code to produce such message in the latest version of 24.*. of course.

hugovk commented 1 week ago

I think it would also be great to agree general policy on which Python versions pip supports in general - and make it a "standard" approach for future migrations as well. This helped a lot in Airflow - we have now policies agreed on that and rather than discussing it, we jus follow the rule we agreed before (or if we want to change the rule, it's clear we need to start a discussion on it including justification for change).

The policy is at https://pip.pypa.io/en/stable/development/release-process/#python-support-policy:

Python Support Policy

pip supports CPython versions that are not end-of-life. Older versions of CPython may be supported at the discretion of pip maintainers (based on criteria such as download statistics on PyPI, Python versions supported by the vendored dependencies and maintenance burden).

sbidoul commented 1 week ago

If 24.3 is the last version to support Python 3.8 I think it would be a big help, for a small number of users, if truststore released with sethmlarson/truststore#157 and it was vendored by pip. Just on the intuition that old versions of MacOS might be using old versions of Python.

If at least pip 25.0 supports Python 3.8 I think it's less important.

@notatallshaw I'm not comfortable with including an unmerged trusttore PR (assuming our vendoring policy would allow it). Can you post that comment on https://github.com/pypa/pip/issues/12989 so we keep track of that there?

notatallshaw commented 1 week ago

I'm not comfortable with including an unmerged trusttore PR (assuming our vendoring policy would allow it). Can you post that comment on #12989 so we keep track of that there?

100% agreed, I didn't mean to imply that, more that if truststore is able to release with that PR merged it would be a great help and would make it easier to consider dropping support for Python 3.8 in 25.0. I did mention it in https://github.com/pypa/pip/issues/12989#issuecomment-2408722710 but I'll add something that's more explicit.

notatallshaw commented 1 week ago

Actually, I withdraw my comments about truststore, I got confused and thought it was doing openssl 1.1.1+ detection, but I see it's actually doing Python version detection: https://github.com/sethmlarson/truststore/blob/v0.9.2/src/truststore/__init__.py#L5

So any vendor of truststore is irrelevant to Python 3.8 and 3.9. Sorry for the noise.

pradyunsg commented 1 week ago

assuming our vendoring policy would allow it

It does not.