Last time I ported dtests during the 4.0 quality test epic there wasn't support for virtual nodes in in-jvm dtests. We have many Python dtests depending on vnodes that can't be totally ported if we still don't have support for vnodes, I don't know if it's still the case.
On Wed, 26 Jan 2022 at 14:02, Joshua McKenzie <jmcken...@apache.org> wrote: > Could be a very fruitful source of LHF tickets to highlight in the > biweekly email and would be pretty trivial to integrate this into the build > lead role (getting an epic and jira tickets created to port tests over, > etc). > > we can run our tests much more quickly, and debug failures much more >> easily. > > Please Yes. If we can get away from python upgrade tests I think all our > lives would be improved. > > I like it. > > > On Wed, Jan 26, 2022 at 8:42 AM bened...@apache.org <bened...@apache.org> > wrote: > >> We could set this as a broad goal of the project, and like the build lead >> role could each volunteer to adopt a test every X weeks. We would have >> migrated in no time, I expect, with this kind of concerted effort, and >> might not even notice a significant penalty to other ongoing work. >> >> >> >> Last time I ported a dtest it was a very easy thing to do. >> >> >> >> I might even venture to predict that it might payoff with lower >> development overhead, as we can run our tests much more quickly, and debug >> failures much more easily. >> >> >> >> *From: *Joshua McKenzie <jmcken...@apache.org> >> *Date: *Wednesday, 26 January 2022 at 13:40 >> *To: *dev <dev@cassandra.apache.org> >> *Subject: *Re: Have we considered static type checking for our python >> libs? >> >> I have yet to encounter this class of problem in the dtests. >> >> It's more about development velocity and convenience than about >> preventing defects in our case, since we're not abusing duck-typing >> everywhere. Every time I have to work on python dtests (for instance, when >> doing build lead work and looking at flaky tests) it's a little irritating >> and I think of this. >> >> >> >> I would hate to expend loads of effort modernising them when the same >> effort could see them superseded by much better versions of the same test. >> >> I completely agree, however this is something someone would have to take >> on as an effort and I don't believe I've seen anybody step up yet. At the >> current rate we're going to be dragging along the python dtests into >> perpetuity. >> >> >> >> >> >> On Wed, Jan 26, 2022 at 8:16 AM bened...@apache.org <bened...@apache.org> >> wrote: >> >> I was sort of hoping we would retire the python dtests before long, at >> least in large part (probably not ever entirely, but 99%). >> >> >> >> I think many of them could be migrated to in-jvm dtests without much >> effort. I would hate to expend loads of effort modernising them when the >> same effort could see them superseded by much better versions of the same >> test. >> >> >> >> >> >> *From: *Joshua McKenzie <jmcken...@apache.org> >> *Date: *Wednesday, 26 January 2022 at 12:59 >> *To: *dev <dev@cassandra.apache.org> >> *Subject: *Have we considered static type checking for our python libs? >> >> Relevant links: >> >> 1) Optional static typing for python: >> https://docs.python.org/3/library/typing.html >> >> 2) Mypy static type checker for python: https://github.com/python/mypy >> >> >> >> So the question - has anyone given any serious thought to introducing >> type hints and a static type checker in ccm and python dtests? A search on >> dev ponymail doesn't turn up anything. >> >> >> >> I've used it pretty extensively in the past and found it incredibly >> helpful combined with other linters in surfacing troublesome edge cases, >> and also found it accelerated development quite a bit. >> >> >> >> Any thoughts on the topic for or against? >> >> >> >> ~Josh >> >>
