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
