Add Plugins View in web UI

[rootcss]

This PR adds a link to view details of Plugins loaded into the Airflow.

closes: #9185

---

^ 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.

[mik-laj]

@mjpieters Can you look at it? Does it meet your expectations?

[mik-laj]

The original ticket mentions the following requirements. What do you think to add them?

- source (plugins folder or entry point)
- for plugins folder plugins
   - path relative to the plugins folder
- for entry point plugins
   - the project name and version from the `EntryPoint.dist` object (using `str(entry_point.dist)` should suffice)
   - the entrypoint name, module and attributes information (`str(entry_point)` provides this, already formatted).
   - **NOT** the file location, that'd be a security issue. The entrypoint information is enough to locate the plugin when someone has access to the machine and the Python installation that runs Airflow.
- Optionally: information on the specific extension points provided by the plug-in.

[rootcss]

@mik-laj currently while loading the plugins from either of the sources, we're not keeping the information about the source, path etc. To get this information, we'd need to probably introduce two attributes (something like plugin_source and plugin_path) for class AirflowPlugin.
While loading the plugins in their specific methods, we can set these attributes to their relevant values.
eg,
In the case of entrypoint based plugins:

plugin_source: entrypoint_plugin
plugin_path: str(entry_point.dist)

In the case of airflow plugins directory based plugins:

plugin_source: airflow_plugins_directory
plugin_path: '/path/to/the/plugin/directory'

Let me know what do you think.

[mjpieters]

The point of my request was to make it visible where the plugin was loaded from, and what version information we have (if any).

Our cluster setup is somewhat complicated with mixed virtualenv and conda layers, being able to see where distutils pulled the plugin from is quite important.

So while this looks cool, it's not what I had in mind.

[rootcss]

hey @mjpieters: Got that. This is a WIP, we're still discussing some of the changes to do that.

[rootcss]

@mjpieters: I've added the plugin source and path attributes. Source tells whether the plugin was loaded from the plugins directory or from the entrypoint package. Plugin Path shows the absolute path of the package in case it's loaded from plugins directory, otherwise shows entry_point.dist incase of entrypoint package.

[rootcss]

@kaxil @mik-laj This PR can be reviewed now.

[rootcss]

@mjpieters Thank you for all the suggestions. Please have a look now. Now we've just one attribute called source for AirflowPlugin: source: Optional[AirflowPluginSource] = None. @kaxil I'd love your feedback on this PR as well.

[mjpieters]

Thanks for implementing all my suggestions! 🎺

[kaxil]

@rootcss Can you please rebase the PR on latest master again 🙏

[rootcss]

@kaxil I've rebased and pushed.

[github-actions]

The Build Workflow run is cancelling this PR. It has some failed jobs matching ^Pylint$,^Static checks$,^Build docs$,^Spell check docs$,^Backport packages$,^Checks: Helm tests$,^Test OpenAPI*.

[kaxil]

tests are failing

[github-actions]

The Workflow run is cancelling this PR. It has some failed jobs matching ^Pylint$,^Static checks$,^Build docs$,^Spell check docs$,^Backport packages$,^Checks: Helm tests$,^Test OpenAPI*.

[rootcss]

@kaxil 3 checks have failed, but I don't see any error messages. Is it a known thing by any chance?

[mik-laj]

@rootcss I restarted the build.

[rootcss]

@mik-laj that fixed it. Thanks.