100% agree with that line of thinking @pf_moore and with proposed approach how to tackle it.
I am going to request (and see maybe already someone did it so I will join the effort from Airflow side) to add support for pipx and uv tool as they are both prime candidates for having it. I am also absolutely fine with us publishing the lockfiles (we can also solve the problem of GitHub reliance this way as we might simply publish it in “airflow.apache.org” similarly as we publish SBOM files CycloneDX SBOMs for Apache Airflow 3.1.1 currently (which hopefully eventually will - be published in the .whl files PEP 770 – Improving measurability of Python packages with Software Bill-of-Materials | peps.python.org → though I also hope - for the reason of potentially regenerating the SBOM with more/updated information eventually those SBOMS will also stop being “immutable” in .whl file.
So except support for installation in pipx and uv tool - we are not blocking to try it out and report it here or in further discussion on our learnings and experiences.
Also BTW. I am not too happy with the way how SBOMS in PEP-770 are going to be embedded in the .whl file. Simlarly for lock files - the fact that both SBOMS and package lock should not (IMHO) be treated as immmutable, this is a bit of problematic choice for me.
Maybe this can be solved by wider acceptance of “post” releases to update such meta-data. I don’t think (and I would love to be corrected on that), that “post” releases are not expected to modify such “sbom” (and maybe futture lock) metadata?
Since “post” is very rarely used (and PEP-440 is not too detailed on what metadata really could be updated in post release (only release notes are explicitly specified). I have a bit of feeling that “post” releases are treated a bit as “ugly child” and their behaviour, scope and usage for post releases. But maybe clarifying that you can update SBOM/LOCK metadata in post releases and (ideally) we could do it easily without recreating the original packages (maybe even just post “empty” post packages with only the metadata changed?) - this would practically allow us to remove the need of publishing the lock files separately - they could be part of the .whl and could be updated in .post releases. From my experience, the constraint files in airflow are MOSTLY IMMUTABLE, we change them extremely rarely in very specific circumstances, it requires us for example to rebuild our “convenience” production images that we also publish, so doing it via “.post” release does not seem to far off.