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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Moves provider packages scripts to dev #12082
Moves provider packages scripts to dev #12082
Changes from all commits
40a587d
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's this needed for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was just about to write about it. The previous way of retrieving version gave already hard time in previous scenarios when setup.py was used while airflow was already installed and in pre-commits. It sometimes did not found version.py. Therefore I've added a change to synchronize version in setup.py and version.py at the pre-commit level. This way there is no importlib call during setup.py execution - version is hard-coded, so there is no risk any problems will happen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This way @ashb -> we do not have any dynamic importing while building/preparing the packages. IMHO it's much more robust and healthy if the version is hard-coded. It is especially a problem in case we want to import stuff like "EXTRAS" etc in setup.py and run those check in various "environments" - for example in pre-commits and in case of scripts that are running outside of "airflow" folder, or when we have airflow installed as pypi package rather than fro sources.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not thrilled about this change.
When, and why, are we importing the top-level setup.py when Airflow is already installed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(This doesn't block us merging this for now)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are at lest few cases:
We are importing it in some python pre-commits to verify setup.py consistency, ordering, completeness
We are importing it when automatically generating provider package setup.py's or when we generate README files for those (we are retrieving information about dependencies for each package so that we can produce a documentation showing those dependencies and add the dependencies in the generated setup.py for providers using a single source of truth.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy if you have other proposals for those.
The provider setup.py and README generation is difficult to be done otherwise unless we built in some dump of dependencies from setup.py in some structured way, but we would need to do it as pre-commit whenever setup.py changes.
We already do that for another case - to generate cross-provider dependencies https://github.com/apache/airflow/blob/master/airflow/providers/dependencies.json - this file is a structured dump of which provider depends on which. It is done from the sources rather than from setup.py automatically using pre-commit.
But I think it would not be a good way to keep that information in two places (setup.py and another .json or similar).
Happy to discuss what other approaches we might take there if you can propose something.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For inspiration - this is how we generate those depenencies.json . I think they are useful to keep to see the dependencies:
This has been working for months now without anyone doing anything to keep those in-sync and I saw quite a few cross-provider dependencies changed between the few provider package releases we had. Thanks to that we do not have to do anything to keep provider's cross-dependencies in sync.
And we have a nice history of changes to those cross-provider deps
This file was deleted.
This file was deleted.
This file was deleted.