[07:46:00] <McSinyx[m]> <graingert "eg say it's 2030 and it turns ou"> still if keeping it under a --use-feature is the price for this to happen, I'd vote for the delay
[09:35:13] <graingert> No I'm more under the impression that the feature will land soon, and the use-feature flag becomes deprecated but never removed
[09:53:38] <McSinyx[m]> I misunderstood and joked about holding 2020-resolver until 2030 to fascilitate the P=NP thing
[09:54:40] <McSinyx[m]> I think per pip's deprecation policy, --use-feature=2020-resolver will be valid in the next 6 months
[09:55:24] <McSinyx[m]> IIRC there'll be a deprecated warning next release (20.3) and it'll be an error 2 releases later (21.1)
[14:27:10] <graingert> is there a neat way to detect that a set of packages don't support the latest of every package?
[14:27:56] <graingert> eg here https://github.com/pytest-dev/pytest/pull/7721/files#diff-b91f3d5bd63fcd17221b267e851608e8R120-R128
[14:28:09] <graingert> I want to fail the test if we don't get the latest version of all these packages
[14:34:02] <graingert> In fact is there a way to list all the packages you have installed with available updates, and those you can upgrade to and those you can't?
[15:02:30] <McSinyx[m]> I think there's a way, but not solely using pip
[15:05:32] <McSinyx[m]> the following should work: [ $(pip list -o | wc -l) -eq 2 ]
[15:06:54] <McSinyx[m]> but it's kind of a hack because pip may print warning, so maybe a less trivial check than wc or giving pip -qqq may help
[15:49:29] <graingert> McSinyx[m]: is there a way to find out what's holding back an upgrade?
[15:50:17] <McSinyx[m]> AFAIK, other than reading the backtracking process, then no
[15:51:01] <McSinyx[m]> I think you might want to file an issue about this, since there's also funded UI/UX rework going on along with the new resolver rollout
[15:52:53] <graingert> McSinyx[m]: lol the issue creation workflow directed me right back here