Skip to content

feat: expose Comet version as spark.comet.version runtime config - #5049

Open
andygrove wants to merge 1 commit into
apache:mainfrom
andygrove:feat/comet-version-runtime-conf
Open

feat: expose Comet version as spark.comet.version runtime config#5049
andygrove wants to merge 1 commit into
apache:mainfrom
andygrove:feat/comet-version-runtime-conf

Conversation

@andygrove

Copy link
Copy Markdown
Member

Which issue does this PR close?

Supersedes #4852.

Rationale for this change

There is currently no convenient way for a Spark user to query which Comet version is loaded. The JVM org.apache.comet.COMET_VERSION constant exists but is only reachable via Scala imports, and the native library logs the version on init but that requires driver log access.

The previous attempt (#4852) exposed the version as a SQL function via SparkSessionExtensions.injectFunction. Review feedback on that PR questioned whether a function was the right mechanism, and registering a function into the session registry also broke the upstream Spark ShowFunctionsSuite tests, since those suites assert on the exact set of registered functions. Exposing the version as a Spark config avoids polluting the function registry entirely and matches how Spark surfaces similar build metadata.

What changes are included in this PR?

  • The Comet driver plugin sets spark.comet.version on the SparkConf during init, so it is queryable at runtime via spark.conf.get("spark.comet.version") or SET spark.comet.version in SQL. It is set before the off-heap check so the version is reported even when Comet is otherwise disabled.
  • Documents both the new spark.comet.version runtime config and the existing org.apache.comet.COMET_VERSION (plus COMET_BRANCH / COMET_REVISION) programmatic accessors in the installation guide.

How are these changes tested?

  • New unit test in CometPluginsSuite (Comet version is exposed as a Spark config) asserting spark.comet.version is visible on both the SparkContext conf and the session runtime config, using the same plugin-loading harness that covers the existing memory-overhead behavior.

Expose the loaded Comet build version through the Spark config
spark.comet.version (set by the Comet driver plugin) so it can be
queried at runtime via spark.conf.get or SET. Also document the
existing org.apache.comet.COMET_VERSION programmatic accessor.
@andygrove andygrove added this to the 1.0.0 milestone Jul 27, 2026
`spark.comet.version`. This can be queried at runtime from any supported language, for example:

```scala
scala> spark.conf.get("spark.comet.version")

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would be nice to get an example output?

```

```sql
SET spark.comet.version;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hardly can imagine scenarios for user to change comet version

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SET shows the current value.

spark-sql (default)> SET spark.sql.adaptive.enabled;
spark.sql.adaptive.enabled	true
Time taken: 0.276 seconds, Fetched 1 row(s)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants