(feat)Python CLI: Switch from Poetry to UV for python package management

[MonkeyCanCode]

Per discussion in https://lists.apache.org/thread/2hlh3rvmgo7ol3qn08xmyf85grck2p35, team preferred uv over poetry. Couple major changes with this PR:

1. Switched from poetry to uv
2. Installed uv in virtualenv instead of system level to avoid potential conflict and keep system clean
3. Used hatch instead of poetry-core/setuptool for build management
4. Used hatch hook for openapi code generator

For the next PR, we can do more cleanup to remove unnecessary code/scripts around virtualenv management and let uv handles those natively if preferred. Currently, it is backward compatible as existed one in term of how to invoke the CLI and run docker-compose.

Checklist

• 🛡️ Don't disclose security issues! (contact security@apache.org)
• 🔗 Clearly explained why the changes are needed, or linked related issues: Fixes #
• 🧪 Added/updated tests with good coverage, or manually tested (and explained how)
• 💡 Added comments for complex logic
• 🧾 Updated CHANGELOG.md (if needed)
• 📚 Updated documentation in site/content/in-dev/unreleased (if needed)

[kevinjqliu]

generally lgtm, i would double check the build artifacts to make sure that its the same as packaged previously using poetry. That tripped us up during the pyiceberg migration

[MonkeyCanCode]

generally lgtm, i would double check the build artifacts to make sure that its the same as packaged previously using poetry. That tripped us up during the pyiceberg migration

Yes, I did that earlier. Most of them are same except wheel one doesn't have the root level init.py (which is fine). One thing caught me earlier was spec as that got excluded from hatch build due to we have spec in gitignore.

[dimas-b]

LGTM, but please wait for more reviews from people who deal with our python CLI more regularly than me :)

[HonahX]

Overall LGTM! Thanks for migrating this! I believe this could also make the release process easier in the future.

One thing I noticed was that the spark getting-started example now miss the ipynb in jupyter lab:

But this may not be relevant to this PR.

[MonkeyCanCode]

Overall LGTM! Thanks for migrating this! I believe this could also make the release process easier in the future.

One thing I noticed was that the spark getting-started example now miss the ipynb in jupyter lab:

But this may not be relevant to this PR.

So this may be due to change of base image that I done long time back where ipynb is not part of jupyterlab library. But do we need this dependency as the current getting started notebook is fully functional.

[kevinjqliu]

LGTM

[HonahX]

LGTM! And feel free to ignore my previous comment about getting-started example. It turns out I am still on the old image....

[kevinjqliu]

It turns out I am still on the old image....

ha i ran into this recently too. adding the --build flag helps auto rebuild apache/iceberg-python#2885

[MonkeyCanCode]

thanks for the review @kevinjqliu, @HonahX , and @dimas-b . @dimas-b any last concern before I merge this one?