Skip to content

Update Makefile for python client with auto setup #1995

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 10 commits into from
Jul 10, 2025

Conversation

MonkeyCanCode
Copy link
Contributor

@MonkeyCanCode MonkeyCanCode commented Jul 2, 2025

The current Makefile and README.md is asking users to setup needed python environment (either virtual or the one installed on the OS) then installed the needed dependencies. I think it makes more senses to automate it and use a virtual env instead to avoid change an end-users' OS python (as if they didn't setup virtual env, the package will needed to be installed on the OS one).

This PR does the following:

  1. updated the existed Makefile with venv setup
  2. update doc to remove ref with manual dependency setup steps
  3. update pre-commit-hook to run against cli/* as well. The current one only ran against integration_tests/*
  4. mypy doesn't appear to be happy with cli/*. Add a files regex for now to skip this check (so existed on with integration_tests/* will still get run
  5. format the code with make lint (2 files modified)
  6. add helper for Makefile
  7. set constant version for poetry

Here is the sample output:

➜ make lint
Installing Poetry and project dependencies into .venv...
# Ensure pip is up-to-date within the venv
.venv/bin/pip install --upgrade pip
Requirement already satisfied: pip in ./.venv/lib/python3.13/site-packages (25.1.1)
# Install poetry if not already present
# Install needed dependencies using poetry
.venv/bin/poetry install --all-extras
Installing dependencies from lock file

No dependencies to install or update

Installing the current project: polaris (1.0.0)
Poetry and dependencies installed.
.venv/bin/poetry run pre-commit run --files integration_tests/* cli/*
trim trailing whitespace.................................................Passed
fix end of files.........................................................Passed
debug statements (python)................................................Passed
ruff check...............................................................Passed
ruff format..............................................................Passed
mypy.....................................................................Passed

Here is the sample helper from Makefile:

➜  make

Usage:
  make <target>
  help                            Display this help.
  version                         Print version information.
  regenerate-client               Regenerate the client code
  test-client                     Run client tests
  test-integration                Run integration tests
  lint                            Run linting checks
  clean                           Cleanup

@MonkeyCanCode MonkeyCanCode mentioned this pull request Jul 2, 2025
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.

@MonkeyCanCode Thanks for improving the Makefile! Overall LGTM

There are some discussion around doing the code check/format in a different way: #1986. Since the current one is an improvement of the existing solution, I suggest we seek to merge this first and change later based on the result of #1986

@MonkeyCanCode
Copy link
Contributor Author

@MonkeyCanCode Thanks for improving the Makefile! Overall LGTM

There are some discussion around doing the code check/format in a different way: #1986. Since the current one is an improvement of the existing solution, I suggest we seek to merge this first and change later based on the result of #1986

Exactly, it is a lot harder to do without this piece first (thinking about using native shell and markfile route instead of a third party plugin which may not be supported after 1-2 years).

@MonkeyCanCode
Copy link
Contributor Author

MonkeyCanCode commented Jul 8, 2025

@MonkeyCanCode Thanks for improving the Makefile! Overall LGTM
There are some discussion around doing the code check/format in a different way: #1986. Since the current one is an improvement of the existing solution, I suggest we seek to merge this first and change later based on the result of #1986

Exactly, it is a lot harder to do without this piece first (thinking about using native shell and markfile route instead of a third party plugin which may not be supported after 1-2 years).

@HonahX please take another look when you get a chance. i added a helper for Makefile as well (update the PR summary to reflect the same):

➜  make

Usage:
  make <target>
  help                            Display this help.
  version                         Print version information.
  regenerate-client               Regenerate the client code
  test-client                     Run client tests
  test-integration                Run integration tests
  lint                            Run linting checks
  clean                           Cleanup

HonahX
HonahX previously approved these changes Jul 10, 2025
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.

LGTM! Just have one comment about the poetry version in installation script

Thanks for improving this!

VERSION ?= $(shell cat pyproject.toml | grep version | sed 's/version *= *"\(.*\)"/\1/')
BUILD_DATE := $(shell date -u +"%Y-%m-%dT%H:%M:%S%:z")
GIT_COMMIT := $(shell git rev-parse HEAD)
POETRY_VERSION := $(shell cat pyproject.toml | grep requires-poetry | sed 's/requires-poetry *= *"\(.*\)"/\1/')
Copy link
Contributor

Choose a reason for hiding this comment

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

The poetry version in pyproject.toml seems not having an upper bound

requires-poetry = ">=2.1"

I think in the installation script we might want to pin the exact version to avoid CI failures due to breaking changes in automatic version update.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So I did thought about this, there are couple reasons on why I did the above:

There are 3 places where we are specify poetry (README.md within this direction...which we said >2.0 will work), regretest (which we defined a specific version, in this case 2.1.3), and pyproject.toml where we said anything >= 2.1 should work. I had updated all 3 pieces to be the same version. Please take another look when you get a chance.

@github-project-automation github-project-automation bot moved this from PRs In Progress to Ready to merge in Basic Kanban Board Jul 10, 2025
@HonahX HonahX merged commit 3b06a80 into apache:main Jul 10, 2025
11 checks passed
@github-project-automation github-project-automation bot moved this from Ready to merge to Done in Basic Kanban Board Jul 10, 2025
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