Consider dropping candidates that have parse errors for resolution instead of failing the installation

[potiuk]

I have really weird issue with latest uv (0.1.28) and I think there is an issue with how errors is parsing candidate metadata might cause the whole build to fail.

In some cases of uv pip install - some old releases of some transitive dependencies with broken metadata might cause the whole installation to fail - even if there are other candidates that are perfectly fine.

This one is pretty similar to one which I opened in the past and closed (#2411) - but this time, I think the way how uv fails is a bit too "panicky".

One of the steps of our CI is building PROD images and while doing it in release branch, we are buding the released airflow from sources to wheel and install it with 'PROD' image extras - which will pull provider packages and a number of transitive dependencies from PyPI.

The command to run is:

uv pip install 'apache-airflow[aiobotocore,amazon,async,celery,cncf-kubernetes,common-io,docker,elasticsearch,ftp,google,google-auth,graphviz,grpc,hashicorp,http,ldap,microsoft-azure,mysql,odbc,openlineage,pandas,postgres,redis,sendgrid,sftp,slack,snowflake,ssh,statsd,uv,virtualenv] @ file:///docker-context-files/apache_airflow-2.9.0-py3-none-any.whl'

This nicely work for Python 3.8 - 3.10 and 3.12, but for Python 3.11 (and only for Python 3.11) it fails with this error:

#64 6.287 error: Failed to download: google-cloud-bigquery==1.28.2
  #64 6.287   Caused by: Couldn't parse metadata of google_cloud_bigquery-1.28.2-py2.py3-none-any.whl from https://files.pythonhosted.org/packages/ce/af/89ccb3dd70a86516cb408dd7b7484d2fdd073bdce6405f722f75e6058e66/google_cloud_bigquery-1.28.2-py2.py3-none-any.whl.metadata
  #64 6.287   Caused by: after parsing 2.0, found "de" after it, which is not part of a valid version
  #64 6.287 pyarrow (<2.0de,>=1.0.0) ; (python_version >= "3.5") and extra == 'all'
  #64 6.287          ^^^^^^

Of course - it's obvious what the problem is with the google-cloud-bigquery package - but this is a REALLLY old version of the package (4 years) and it's not the one that the installation should resolve to. All the previous resolutions correctly resolved it to google-cloud-bigquery==3.20.1 - which is latest version released on 1st of April (not an April's fool joke). But the PROD image installation somehow fails the whole uv pip install fails - because of that wrong metadata, in package version that should not even be considered.

I am attempting to battle this in two ways:

1. add a more direct dependency to the future provider (and lower-bind it) Add google-cloud-bigquery as explicit google-provider dependency apache/airflow#38753
2. switch back to pip for "Release" PROD builds when we do PROD image building using pip rather than locally build providers (which we use in main : Switch to pip for all PROD images built in the release branches apache/airflow#38749 and Also disable UV for PROD cache build in release branches apache/airflow#38752

I am not sure if 1. will help, 2. should help for sure - (and for now we anyhow use pip to install airflow in "real" PROD image - so that is going to stay likely (release branches should be as close to "production" releases as possible) - but it would be cool to investigate and see why such a metadata issue in an old version that is not really even going to be used is causing the whole installation to fail. It does not seem too robust if someone could release (or have released in the past) an old, broken version of the package that would break new installation for new versions of the same package (being transitive dependency)

Link to show thee failure (logs will disappear in 30 days or so) : https://github.com/apache/airflow/actions/runs/8555464849/job/23446007205#step:10:3693 - and you can see that it's only Python 3.11 that fails (which is even stranger).

[zanieb]

Thanks for all the details! I'm not sure why we're backtracking so far here, but you can see some more information about the general problem at #1398

Reasonable lower bounds are definitely a good solution to help a resolver in a situation like this.

I'm not sure about dropping the candidates vs failing — cc @konstin.

[charliermarsh]

This looks similar to #1800.

[charliermarsh]

I think we should be skipping invalid candidates...

[charliermarsh]

We do this in some cases already though. I'm trying to remember when.

[potiuk]

I think we should be skipping invalid candidates...

Yeah. Sounds about right :) . They are invalid and won't be installed anyway, so we might very safely reject them :)

[charliermarsh]

Ah okay, we skip when parsing the simple metadata responses, since those can contain invalid Requires-Python markers. We should similarly skip-and-warn for distributions with invalid metadata.

[charliermarsh]

I can do this tomorrow as a fun thing, it seems interesting.