Adds providers information to airflow info command
#12687
Conversation
potiuk
force-pushed
the
add-provider-information-to-airflow-info-command
branch
from
067be17
to
e77b873
Compare
github-actions
bot
added
the
okay to merge
|
The PR should be OK to be merged with just subset of tests as it does not modify Core of Airflow. The committers might merge it or can add a label 'full tests needed' and re-run it to run all tests if they see it is needed! |
| 'Provider name': provider['package-name'], | ||
| 'Version': provider['versions'][0], | ||
| } | ||
| for version, provider in ProvidersManager().providers.values() |
There was a problem hiding this comment.
@potiuk , better to have this version replaced by _ given it is not used here? Or if I missed anything? of course it's a nit.
There was a problem hiding this comment.
Or provider['versions'][0] above should be replaced by version from this line?
Based on my understanding from https://github.com/apache/airflow/blob/master/airflow/providers_manager.py#L169-L171
May be wrong though of course, and as mentioned above, this is minor
There was a problem hiding this comment.
@XD-DENG - > True, good eye, We need to still implement final versioning information for providers. And it is simple (but not minor :). I think it is critical before we release 2.0.
For now this information might be in three places: we have list of versions in provider.yaml (for documentation purpose) and we have version of currently installed version in the provider package, and (for now) all the versions for all provider packages are hard-coded when released (to 1.0.0b2). This has to be synced-up automatically and we have to describe how to update the versions when you add changes to provider (and whethere to increase majonr/minor/patchlevel for it).
And it should work in both cases - when we run Airlfow directly from sources during development and unit tests (there provider.yaml files are read) or when we are running in production and provider is installed from the packages (then we read version information from the package). For now I just take versions[0] as this information is available in all cases (but it might be not accurate and for example might not match the version of the package).
The issue for that is here: #11425 - which we still need to complete it before 2.0.0rc1 - it is mostly about making sure that package versions in provider.yaml and the version that is currently being released are in sync and that we know how to update it in-the future, separately for each package.
Not complex but important :).
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code change, 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 UPDATING.md.