MonkeyCanCode commented on PR #1986: URL: https://github.com/apache/polaris/pull/1986#issuecomment-3030853669
> @HonahX > > > Do we want to add python format check to gradle because we want format issue stops CI before enterring the real test cases? > > I'd like to have the same setup as the rest of the code -- CI fails if you have a format issue, and `./gradlew format` fixes it. > > > IMHO, the python client should be isolated from the main java project and all the dependency management/test/checking should happen with in that folder via poetry and some other python specific tools. And format failure or test failure should not cause irrelevant CI workflow to fail (e.g. Java Gradle test) > > It makes sense to use python-specific tooling (ruff?) and to have python-specific commands... but the gradle task `checkstyleMain` isn't called `checkStyleJava`. > > We already check the python code in the gradle task `copiedCodeChecks` and as you pointed out we also have the (short-lived?) gradle task `regeneratePythonClient`. Having a gradle task to check/fix style issues seems convenient and not a huge leap from what we already have. > > Agreed that irrelevant CI shouldn't fail -- but there actually is no CI action called Jave Gradle test... `Regression Tests` is failing, for example, but that's not Java specific and in fact runs Python code today. The Python CI should ideally fail if there are Python style issues. @HonahX a bit more context on this PR: While i was checking for what to pick up next, I was not aware we have a Makefile that does this already and noticed the code has a bit free-style. Thus, I ended up ran a manual ruff locally to format the code then check-in the changes (https://github.com/apache/polaris/pull/1954). As part of this PR, @eric-maynard suggests we should automate this as part of check-in as how we are doing today such as spotless apply for formatting java code. Thus, I began explore what options are out there with gradle. It turns out there is no a popular plugin for gradle to work with python (the one from LinkedIn has no new release since 2020). At that points, I really have 2 options: 1. find a working plugin with gradle that will work with python (which is current approach) 2. use other approach outside gradle and enforce it with GH action (which then I found out that already existed...side note, I raised an enhancement PR for this approach: https://github.com/apache/polaris/pull/1954...if we really like one command from gradle, we can always have gradle run exec with make command from the enhancement PR) With option one, i think the main benefit is people don't need to know another command to run (assuming everyone is happy with gradle...personally, makefile is a lot easier to use imo and we can create some very powerful makefile to control various tasks). That being said, I am fine with any of the approach and also open to new approach. Let me know what you think. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
