Vendor-in json-merge-patch and add --no-dev to direct uv tool install #48210
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
boring-cyborg
bot
added
area:dev-tools
area:providers
provider:apache-spark
provider:apache-kylin
provider:google
potiuk
force-pushed
the
workaround-setuptools-mayhem
branch
from
3bd090d to
7cb9d34
Compare
ashb
approved these changes
Mar 24, 2025
vincbeck
approved these changes
Mar 24, 2025
Member
Author
|
Ok. Seems that limiting setuptools in devel deps is not enough - I will add it to main airlfow deps for now |
potiuk
force-pushed
the
workaround-setuptools-mayhem
branch
from
7cb9d34 to
b53d0b6
Compare
Member
Author
|
Let's see this time |
potiuk
force-pushed
the
workaround-setuptools-mayhem
branch
from
b53d0b6 to
d7cd6fb
Compare
Member
Author
|
And .. note to self .. naming both your module and function as |
bugraoz93
approved these changes
Mar 24, 2025
Contributor
|
Thanks for the fix, Jarek! I'm just catching up with the mayhem. |
Member
Author
|
Unfortunately more fixes needed |
potiuk
force-pushed
the
workaround-setuptools-mayhem
branch
from
d7cd6fb to
98451a0
Compare
Member
Author
|
Another attempt |
kaxil
approved these changes
Mar 24, 2025
Member
Author
|
Geeee.. also |
Member
Author
|
What a buuuuuuumer |
Member
Author
|
ok. Setuptools |
Contributor
Great news! |
potiuk
force-pushed
the
workaround-setuptools-mayhem
branch
from
98451a0 to
91001c0
Compare
potiuk
changed the title
Member
Author
|
Updated the description/title to reflect the actual scope. Actually it's been an interesting case and few small fixes were applied after it :) |
vincbeck
approved these changes
Mar 24, 2025
gopidesupavan
approved these changes
Mar 24, 2025
The setuptools 78.0.1 started to fail old packages that had dash metadata keys and had only .sdist installation. This caused failures of three of our dependencies: * json-merge-patch * pykylin * pyspark The `josn-merge-patch` is a library released in 2017 (v 0.2) that implements the [RFC7386](https://datatracker.ietf.org/doc/html/rfc7386) standard of patching json. It has been used in only one place in our repo in google provider, in order to merge json patches (well - obvious :). Seems like the best approach is to vendor-in the code (70 lines or so) rather than rely on 2017-released package The change also revealed that in pre-commit we could use `--no-dev` flag to skip installing development dependencies, because we only care about the codegen deps.
potiuk
force-pushed
the
workaround-setuptools-mayhem
branch
from
91001c0 to
63dec40
Compare
Member
Author
|
Random k8s issue. Merging |
abhishekbhakat
pushed a commit
to abhishekbhakat/my_airflow
that referenced
this pull request
Mar 25, 2025
…ll (apache#48210) The setuptools 78.0.1 started to fail old packages that had dash metadata keys and had only .sdist installation. This caused failures of three of our dependencies: * json-merge-patch * pykylin * pyspark The `josn-merge-patch` is a library released in 2017 (v 0.2) that implements the [RFC7386](https://datatracker.ietf.org/doc/html/rfc7386) standard of patching json. It has been used in only one place in our repo in google provider, in order to merge json patches (well - obvious :). Seems like the best approach is to vendor-in the code (70 lines or so) rather than rely on 2017-released package The change also revealed that in pre-commit we could use `--no-dev` flag to skip installing development dependencies, because we only care about the codegen deps.
pankajkoti
pushed a commit
to astronomer/airflow
that referenced
this pull request
Mar 28, 2025
…ll (apache#48210) The setuptools 78.0.1 started to fail old packages that had dash metadata keys and had only .sdist installation. This caused failures of three of our dependencies: * json-merge-patch * pykylin * pyspark The `josn-merge-patch` is a library released in 2017 (v 0.2) that implements the [RFC7386](https://datatracker.ietf.org/doc/html/rfc7386) standard of patching json. It has been used in only one place in our repo in google provider, in order to merge json patches (well - obvious :). Seems like the best approach is to vendor-in the code (70 lines or so) rather than rely on 2017-released package The change also revealed that in pre-commit we could use `--no-dev` flag to skip installing development dependencies, because we only care about the codegen deps.
shubham-pyc
pushed a commit
to shubham-pyc/airflow
that referenced
this pull request
Apr 2, 2025
…ll (apache#48210) The setuptools 78.0.1 started to fail old packages that had dash metadata keys and had only .sdist installation. This caused failures of three of our dependencies: * json-merge-patch * pykylin * pyspark The `josn-merge-patch` is a library released in 2017 (v 0.2) that implements the [RFC7386](https://datatracker.ietf.org/doc/html/rfc7386) standard of patching json. It has been used in only one place in our repo in google provider, in order to merge json patches (well - obvious :). Seems like the best approach is to vendor-in the code (70 lines or so) rather than rely on 2017-released package The change also revealed that in pre-commit we could use `--no-dev` flag to skip installing development dependencies, because we only care about the codegen deps.
nailo2c
pushed a commit
to nailo2c/airflow
that referenced
this pull request
Apr 4, 2025
…ll (apache#48210) The setuptools 78.0.1 started to fail old packages that had dash metadata keys and had only .sdist installation. This caused failures of three of our dependencies: * json-merge-patch * pykylin * pyspark The `josn-merge-patch` is a library released in 2017 (v 0.2) that implements the [RFC7386](https://datatracker.ietf.org/doc/html/rfc7386) standard of patching json. It has been used in only one place in our repo in google provider, in order to merge json patches (well - obvious :). Seems like the best approach is to vendor-in the code (70 lines or so) rather than rely on 2017-released package The change also revealed that in pre-commit we could use `--no-dev` flag to skip installing development dependencies, because we only care about the codegen deps.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The setuptools 78.0.1 started to fail old packages that had dash
metadata keys and had only .sdist installation. This caused failures
of three of our dependencies:
The
josn-merge-patchis a library released in 2017 (v 0.2) that implementsthe RFC7386 standard
of patching json. It has been used in only one place in our repo
in google provider, in order to merge json patches (well - obvious :).
Seems like the best approach is to vendor-in the code (70 lines or so)
rather than rely on 2017-released package
The change also revealed that in two places we could use
--no-devflag to skip installing development dependencies, because in both cases
we only care about the actual deps (codegen in case of task-sdk module
and only PyPI / production dependencies for constraint generation
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named
{pr_number}.significant.rstor{issue_number}.significant.rst, in newsfragments.