Hi Eric That's a good point. I think that it's something we can manage with each tool in a separate folder/module. And, I'm sure we will find a solution if/when the problem will occur :)
Regards JB On Mon, Mar 24, 2025 at 5:51 PM Eric Maynard <eric.w.mayn...@gmail.com> wrote: > > +1 to what JB said. > > My concern with Scala has mostly been that it can alienate new contributors > and add ambiguity about when we should use Scala vs. Java. If we’re putting > this in polaris-tools for now and the philosophy for polaris-tools is to > more or less use whatever language you prefer, there should be no issues. > > It does make me think that we should more or less isolate each other “tool” > though. What if contributor A wants a different version of a language or > dependence compared to contributor B? But that’s something we can figure > out as we go. > > On Mon, Mar 24, 2025 at 1:46 AM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > > > Hi, > > > > Personally, I'm more in favor of hosting the benchmark tool in > > polaris-tools (it looks logical :)). > > > > Now, about Scala, and generally speaking about "maintenance > > questions", I think we should not consider what we (individuals) can > > or want to maintain, but more, what the community (including all > > contributors) can/would like to maintain. > > If we take an analogy with Apache Iceberg, Apache Arrow or Apache > > Beam, we can see python, rust, go, maintained by the community, > > whereas it was not probably not the main "skill" from the first > > committers. > > > > So, I don't consider Scala as a question. I also am more in favor of > > moving forward, adding scala support on polaris-tools repo. In the > > lifetime of a project, things can change and refactoring happens, so > > we will always be able to replace Scala or find alternative (to the > > benchmark tool) if there's an ask from the community. > > > > My $0.10 :) > > > > Regards > > JB > > > > On Sun, Mar 23, 2025 at 4:42 PM Michael Collado <collado.m...@gmail.com> > > wrote: > > > > > > Personally, I don’t mind if have to maintain a bit of Scala code - I like > > > Scala, though every time the question of using comes up, I see the same > > > concerns that Russell brought up. > > > > > > I will say that if the alternative is to introduce JMeter into the repo, > > > I’m a hard -1. I’ll write Scala all day long to avoid that. > > > > > > Mike > > > > > > On Sat, Mar 22, 2025 at 1:13 PM Russell Spitzer < > > russell.spit...@gmail.com> > > > wrote: > > > > > > > I think we should start a new thread just to gauge consensus on whether > > > > Scala will be allowed in the tools repository or not. To go through my > > > > quick thoughts here. > > > > > > > > I like Scala but I have to be realistic in saying that it is a rather > > > > esoteric language choice and limits the number of community members > > that > > > > can contribute. So it would be a hard -1 for it being included in the > > main > > > > repository. > > > > > > > > Now for the tools repository I would also be a -1 for brand new > > proposals > > > > without code. Scala raises the bar for contributing so it still > > wouldn't be > > > > a great thing to add when other language bindings exist that are much > > more > > > > popular (even if we didn't chose Java) > > > > > > > > The current situation is a little different as we already have code > > written > > > > and I am usually focused on immediate practical benefits over > > hypothetical > > > > problems. So in the current situation I'm more of a -.1. The reason I > > am > > > > still negative is that inclusion of the benchmarks into the project > > isn't > > > > just about utility to the project, but about whether the community > > should > > > > take up responsibility for maintaining the code. What is important > > here is > > > > not whether the code can be used by the project and contributors but > > about > > > > whether we have enough contributors who are familiar with Scala that > > the > > > > benchmarks can be maintained. We don't want to be in a situation where > > you > > > > win the lottery and we are left high and dry :) > > > > > > > > The value of the code is clearly high, but whether or not it is > > reasonable > > > > for the community to take on responsibility for Scala code (and build) > > > > needs to be polled. As long as a significant fraction of contributors > > don't > > > > have a problem working on Scala code I'm a +1. > > > > > > > > If this contribution was in Java or Python I would be +1 without > > > > reservation. > > > > > > > > > > > > On Sat, Mar 22, 2025 at 12:06 PM Pierre Laporte <pie...@pingtimeout.fr > > > > > > > wrote: > > > > > > > > > I don't mind contributing the benchmarks to `polaris-tools`. It > > seems > > > > that > > > > > the consensus is clearly in that direction. > > > > > > > > > > I want to address some comments that were made in the PR but that > > are not > > > > > really related to code review per se. > > > > > > > > > > > You can write gatling benchmarks in a language other than Scala. > > > > > > > > > > > > There are also frameworks other than gatling. > > > > > > > > > > To me, the big question is : Assuming the code goes to > > `polaris-tools`, > > > > > _will this contribution be rejected if it uses Scala?_ > > > > > > > > > > I understand that this is a controversial topic, and how that the > > > > expected > > > > > maintenance cost is a key factor here. I made sure that the code is > > > > > documented and that a comprehensive readme file describes how > > datasets > > > > > work. That way, nobody needs to be a Scala developer to leverage or > > > > > understand the tool. > > > > > > > > > > Those benchmarks have already been used to detect, reproduce and fix > > > > > multiple issues in the codebase. Issues that had not been caught > > before > > > > > [1] [2] [3]. This shows that the benchmarks already bring value to > > the > > > > > community in their current state. > > > > > > > > > > Now, I want to avoid any misunderstanding. My current focus is on > > > > evolving > > > > > the benchmarks and covering new cases. Not on completely rewriting > > the > > > > > code in Java/another framework. Essentially: focus on the area that > > > > brings > > > > > the most value to Polaris users. > > > > > > > > > > Hence my asking on dev@. If anything, there will be more Scala code > > > > > pushed > > > > > to the benchmarks branch in the upcoming weeks. Not less. I would > > > > > completely understand if the Gatling/Scala design choice is a reason > > for > > > > > rejection. The discussion simply needs to happen. > > > > > > > > > > [1] https://github.com/apache/polaris/issues/1044 > > > > > [2] https://github.com/apache/polaris/issues/1076 > > > > > [3] https://github.com/apache/polaris/issues/1123 > > > > > > > > > > > > > > > -- > > > > > > > > > > Pierre > > > > > > > > > > > > > > > On Sat, Mar 22, 2025 at 3:47 PM Russell Spitzer < > > > > russell.spit...@gmail.com > > > > > > > > > > > wrote: > > > > > > > > > > > I think it makes sense for us to also build some capabilities into > > the > > > > > > tools repo to build Polaris at a specific commit for testing > > purposes. > > > > If > > > > > > the Spark Catalog and Benchmarking code goes there they could both > > > > share > > > > > > this code for testing, ditto for the migration code. > > > > > > > > > > > > On Fri, Mar 21, 2025 at 4:59 PM Yufei Gu <flyrain...@gmail.com> > > wrote: > > > > > > > > > > > > > I’m leaning toward placing it in a separate repository rather > > than in > > > > > > > https://github.com/apache/polaris. The benchmark tool is largely > > > > > > > self-contained and doesn’t have a strong dependency on the main > > > > > codebase. > > > > > > > > > > > > > > IIUC, the only requirement is a running Polaris instance, which > > the > > > > > tool > > > > > > > can connect to using the following configuration: > > > > > > > export CLIENT_ID=your_client_id > > > > > > > export CLIENT_SECRET=your_client_secret > > > > > > > export BASE_URL=http://your-polaris-instance:8181 > > > > > > > > > > > > > > Yufei > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 20, 2025 at 6:05 AM Jean-Baptiste Onofré < > > > > j...@nanthrax.net> > > > > > > > wrote: > > > > > > > > > > > > > > > Hi Ajantha, > > > > > > > > > > > > > > > > That's a good request. > > > > > > > > > > > > > > > > Imho, right now, before distributing any artifact (either on > > > > nightly > > > > > > > > build space https://nightlies.apache.org/), I prefer to have > > it > > > > > "good > > > > > > > > enough" from a "legal" standpoint (e.g. LICENSE/NOTICE). > > > > > > > > > > > > > > > > I'm almost done about that for all artifacts (jar and > > > > distributions). > > > > > > > > I will open a PR soon. > > > > > > > > Once this PR is done, I will submit a way to provide nightly > > > > builds. > > > > > > > > > > > > > > > > Regards > > > > > > > > JB > > > > > > > > > > > > > > > > On Thu, Mar 20, 2025 at 10:27 AM Ajantha Bhat < > > > > ajanthab...@gmail.com > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > I cannot think of any issue with storing that code in the > > > > > > > polaris-tools > > > > > > > > > repository. > > > > > > > > > > > > > > > > > > While contributing the `catalog migrator tool` to > > > > `polaris-tools`, > > > > > I > > > > > > > > > encountered a challenge because this external repository > > needs to > > > > > > > depend > > > > > > > > on > > > > > > > > > Apache Polaris jars, which haven't been published yet by > > Apache > > > > > > > Polaris. > > > > > > > > If > > > > > > > > > we keep the tool in polaris-tools, we may need to wait for > > the > > > > > > nightly > > > > > > > > > build or official jar publication. > > > > > > > > > > > > > > > > > > - Ajantha > > > > > > > > > > > > > > > > > > On Thu, Mar 20, 2025 at 2:46 PM Pierre Laporte < > > > > > > pie...@pingtimeout.fr> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > On Wed, Mar 19, 2025 at 4:53 PM Jean-Baptiste Onofré < > > > > > > > j...@nanthrax.net> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Hi Pierre > > > > > > > > > > > > > > > > > > > > > > Thanks ! > > > > > > > > > > > > > > > > > > > > > > I have a general comment: do we want the benchmark tool > > as > > > > part > > > > > > of > > > > > > > > > > > Polaris "core" repo or on polaris-tools ? > > > > > > > > > > > As we can consider this as a benchmark "tool", maybe it > > makes > > > > > > sense > > > > > > > > to > > > > > > > > > > > host it in https://github.com/apache/polaris-tools. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > At this point, apart from the Gradle build files, the > > benchmark > > > > > > code > > > > > > > is > > > > > > > > > > completely contained under the benchmarks/ directory. And > > > > given > > > > > it > > > > > > > > relies > > > > > > > > > > on the REST API, there is no real dependency to any > > specific > > > > > > Polaris > > > > > > > > > > version. > > > > > > > > > > > > > > > > > > > > I cannot think of any issue with storing that code in the > > > > > > > polaris-tools > > > > > > > > > > repository. > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > Pierre > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
