Skip to content

Conversation

@MonkeyCanCode
Copy link
Contributor

@MonkeyCanCode MonkeyCanCode commented Sep 17, 2025

This is for adding a client build task to Gradle as requested via https://github.com/apache/polaris/pull/2530/files:

➜  polaris git:(gradle_client_build) ./gradlew buildPythonClient
Starting a Gradle Daemon (subsequent builds will be faster)
Configuration on demand is an incubating feature.

> Task :buildPythonClient
Installing Poetry and project dependencies into .venv...
Requirement already satisfied: pip in ./.venv/lib/python3.13/site-packages (25.2)
Installing dependencies from lock file

No dependencies to install or update

Installing the current project: polaris (1.1.0)
Preparing build environment with build-system requirements poetry-core>=2.0.0,<3.0.0, openapi-generator-cli==7.11.0.post0
Preparing spec directory...
Copying spec directory from /Users/yong/Desktop/GitHome/polaris/spec to /Users/yong/Desktop/GitHome/polaris/client/python/spec
Spec directory copied to ensure it is up-to-date.
Deleting old tests...
Old test deletion complete.
Re-applying license headers...
License fix complete.
Poetry and dependencies installed.
--- Building client distribution ---
Building polaris (1.1.0)
Building sdist
Building wheel
--- Client distribution build complete ---

[Incubating] Problems report is available at: file:///Users/yong/Desktop/GitHome/polaris/build/reports/problems/problems-report.html

Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

For more on this, please refer to https://docs.gradle.org/8.14.3/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.

BUILD SUCCESSFUL in 47s
10 actionable tasks: 1 executed, 9 up-to-date

As @HonahX pointed out, poetry only build wheel specific for the OS/hardware where this was executed. Thus, if we want to include diff wheel files (one for each support OS/hardware), we will need to do it via cibuildwheel instead. However, if we only need the dist of code, client/python/dist/polaris-1.1.0.tar.gz is safe to use and it is installable as well:

(venv) ➜  test pip install /Users/yong/Desktop/GitHome/polaris/client/python/dist/polaris-1.1.0.tar.gz
Processing /Users/yong/Desktop/GitHome/polaris/client/python/dist/polaris-1.1.0.tar.gz
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
...

Copy link
Contributor

@HonahX HonahX left a comment

Choose a reason for hiding this comment

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

Thanks for the quick PR! Seems it need rebase to pick up the fix for cryptography license issue

description = "Build the python client"

workingDir = project.projectDir
commandLine("make", "client-build")
Copy link
Contributor

Choose a reason for hiding this comment

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

Some thoughts: Shall we add an option to build only sdist? Underlying it would be

poetry build --format=sdist

Could be useful in some case when we only want sdist : )

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Some thoughts: Shall we add an option to build only sdist? Underlying it would be

poetry build --format=sdist

Could be useful in some case when we only want sdist : )

Good suggestion. Let me quickly add that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@HonahX this is added. Instead of hard-coded it, it is now controlled via FORMAT when using the Makefile such as following:

# build both
make client-build
# build sdist
FORMAT=sdist make client-build
# build wheel
FORMAT=wheel make client-build

When using gradle, it is control via python.format:

# build both
./gradlew buildPythonClient
# build sdist
./gradlew buildPythonClient -Ppython.format=sdist
# build wheel
./gradlew buildPythonClient -Ppython.format=wheel

Copy link
Contributor

Choose a reason for hiding this comment

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

That looks great! Thanks for adding it!

@github-project-automation github-project-automation bot moved this from PRs In Progress to Ready to merge in Basic Kanban Board Sep 18, 2025
@MonkeyCanCode MonkeyCanCode merged commit 149c19e into apache:main Sep 18, 2025
14 checks passed
@github-project-automation github-project-automation bot moved this from Ready to merge to Done in Basic Kanban Board Sep 18, 2025
excludes.add("**/*.png")
}

tasks.register<Exec>("buildPythonClient") {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it hooked up to any "regular" top-level commands?

Should we run it in CI for verification?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Seems like I merged too early. Currently it is not linked with any top level commands, but that is possible if we want to do so. The current CI is using the make command only. There is a WIP PR which needs this.

Copy link
Contributor

Choose a reason for hiding this comment

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

Linking to top-level commands is not critical... I was just wondering. If we connect it, I'd suggest connecting to the assemble chain.

Validating this new tasks in CI would be really good to have, but it's ok to do that in a follow-up PR, of course :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the feedback. Let me review this later tonight or tomorrow then purpose a new PR.

snazy added a commit to snazy/polaris that referenced this pull request Nov 20, 2025
* docs(README): Create Polaris-Core README (apache#2585)

* docs(README): Create Polaris-Core README

* Add Events for Iceberg REST APIs (apache#2480)

* Update dependency com.google.guava:guava to v33.5.0-jre (apache#2601)

* Bump: Iceberg client in tests and documentation to 1.10 (apache#2588)

* Add client build to Gradle (apache#2590)

* Add client build to Gradle

* Add overwrite option for python build

* Match client build behavior

* Add content to contributing guidelines. (apache#2536)

Add community guidelines.

* CI/Caching: Fix Gradle cache retention (apache#2604)

Older versions of Gradle's setup-gradle action did not actively trigger stale cache entry cleanup, which is why there was a separate step "Trigger Gradle home cleanup" in `gradle.yml`.
Nowadays, that action triggers a "noop build" to explicitly trigger stale cache entry cleanup, but uses somewhat different defaults than [described here](https://docs.gradle.org/current/userguide/directory_layout.html#dir:gradle_user_home:configure_cache_cleanup).

This change adds an explicit configuration for Gradle cache cleanup/retention with reasonable values considering the total 10GB limit for all GitHub caches per repository.

The change described above lead to a behavioral change, which evicts all non-accessed cache entries within the current GH workflow job, which effectively evicted all cache entries from dependent jobs - in other words: the (build) cache was nearly empty, leading to full rebuilds.
This behavior could be observed in the output of the "Post Collect partial Gradle build caches"-step in the log message "Build cache (/home/runner/.gradle/caches/build-cache-1) removing files not accessed on or after ..." showing the timestamp when the setup-gradle action was started.

* Last merged commit d8602f6

---------

Co-authored-by: Adam Christian <105929021+adam-christian-software@users.noreply.github.com>
Co-authored-by: Adnan Hemani <adnan.h@berkeley.edu>
Co-authored-by: Mend Renovate <bot@renovateapp.com>
Co-authored-by: Prashant Singh <35593236+singhpk234@users.noreply.github.com>
Co-authored-by: Yong Zheng <yongzheng0809@gmail.com>
Co-authored-by: JB Onofré <jbonofre@apache.org>
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.

3 participants