I agree with all 3 statements here :) So, the short-term plan sounds like: 1. Port Joe's branch to uv. 2. Copy-paste currently used signal-processing code to Otava. 3. Finish the upgrade OR find the next issue.
Best, Alex On Tue, Aug 5, 2025 at 2:46 PM Henrik Ingo <hen...@nyrkio.com> wrote: > I thought about the signal processing code today and have an opinion: > - Thiscode really belongs in the same repo, so we should just go ahead and > add it. I wouldn't even call it vendoring, I expect the division to > disappear soon after we bring the two halves together. > - Regarding which version to work with, we should in any case just start > with the version we consume now (1.5.somethiing?). > - If we then want to upgrade to the newest version we would do it as a > stream of separate commits and so that you can follow the changes both to > Otava code and e-divisive code in the same commit. > > When you break it down this way, it turns out we can go ahead and do 1 and > 2 , and 3 we can discuss with MongoDB perf team when they have time. > > henrik > > On Tue, Aug 5, 2025 at 8:19 PM Alexander Sorokoumov < > aleksandr.sorokou...@gmail.com> wrote: > > > I agree that updating the Python version is the most pressing sweeping > > issue that also blocks adoption and the biggest challenge there is > deciding > > what to do with signal processing code. I propose to vendor the necessary > > code from 1.3.5 to a module within Otava today (naturally, with giving > > credit and referring to the original source code) and discuss > collaboration > > modes async when MongoDB folks respond on the other thread. > > > > Best, > > Alex > > > > On Tue, Aug 5, 2025 at 5:25 AM Henrik Ingo <hen...@nyrkio.com> wrote: > > > > > By the way, now that uv is merged, is there also a plan to jump forward > > on > > > python versions? > > > > > > More generally what I'm really asking is, do we still have many > > "sweeping" > > > changes left. Changes that we may want to get out of the way before > > opening > > > up to general hacking on new features and such? > > > > > > I guess deciding on the location of the e-divisive / signal processing > > code > > > is somewhat sweeping, even if not as much in your face as chaning the > > > project name or build tool. > > > > > > henrik > > > > > > On Tue, Aug 5, 2025 at 1:02 PM Henrik Ingo <hen...@nyrkio.com> wrote: > > > > > > > First ever public discussion about a technical change in Otava! Feels > > > > right. > > > > > > > > On Tue, Aug 5, 2025 at 6:04 AM Dave Fisher <w...@apache.org> wrote: > > > > > > > >> As a mentor I want to give a meta +1 that you had this discussion on > > the > > > >> dev list. > > > >> > > > >> > On Aug 4, 2025, at 4:18 AM, Lari Hotari <lhot...@apache.org> > wrote: > > > >> > > > > >> > +1 for using uv. > > > >> > > > > >> > -Lari > > > >> > > > > >> > On Tue, 29 Jul 2025 at 01:28, Alexander Sorokoumov > > > >> > <aleksandr.sorokou...@gmail.com> wrote: > > > >> >> > > > >> >> Hey everyone, > > > >> >> > > > >> >> This change is significant, so I wanted to open a discussion > about > > it > > > >> first. > > > >> >> > > > >> >> The main motivation for this change has been that the current > > Poetry > > > >> >> version does not support later Python versions and newer Poetry > > > >> versions do > > > >> >> not support our current project config format. Since the build > > system > > > >> >> upgrade requires additional effort, I was wondering if it is time > > to > > > >> shop > > > >> >> for an alternative and did find uv. > > > >> >> > > > >> >> In my opinion, uv is a more promising alternative for 2 reasons: > > > >> >> > > > >> >> 1. It follows an approach similar to build tools one can find in > > > other > > > >> >> ecosystems (looking at Maven/Bazel/Gradle). It is a single > > > entry-point > > > >> to > > > >> >> manage dependencies, python versions, build and upload artifacts, > > > etc. > > > >> I > > > >> >> did not find a way to also run tests and benchmarks without > > > >> tox/pytest, but > > > >> >> it is definitely a step in the right direction IMO. > > > >> >> 2. It is fast. I encourage reviewers to compare how long it takes > > to > > > >> sync > > > >> >> dependencies or re-build a lock file with uv vs Poetry. > > > >> >> > > > >> >> I have opened a PR to showcase what the project will look like > > after > > > >> this > > > >> >> change https://github.com/apache/otava/pull/80. > > > >> >> > > > >> >> Please let me know what you think. > > > >> >> > > > >> >> Best, > > > >> >> Alex > > > >> > > > >> > > > > > > > > -- > > > > *nyrkio.com <http://nyrkio.com/>* ~ *git blame for performance* > > > > > > > > Henrik Ingo, CEO > > > > hen...@nyrkio.com LinkedIn: > > > > www.linkedin.com/in/heingo > > > > +358 40 569 7354 Twitter: > > > > twitter.com/h_ingo > > > > > > > > > > > > > -- > > > *nyrkio.com <http://nyrkio.com/>* ~ *git blame for performance* > > > > > > Henrik Ingo, CEO > > > hen...@nyrkio.com LinkedIn: > > > www.linkedin.com/in/heingo > > > +358 40 569 7354 Twitter: > > > twitter.com/h_ingo > > > > > > > > -- > *nyrkio.com <http://nyrkio.com/>* ~ *git blame for performance* > > Henrik Ingo, CEO > hen...@nyrkio.com LinkedIn: > www.linkedin.com/in/heingo > +358 40 569 7354 Twitter: > twitter.com/h_ingo >
