Open Stack

On Wed, 2021-02-10 at 12:00 +0000, Stephen Finucane wrote:
> On Wed, 2021-02-10 at 08:20 +0000, Sorin Sbarnea wrote:
> > While switch from testr to stestr is a no brainer short term move, I want to
> > mention the maintenance risks.
> > 
> > I personally see the stestr test dependency a liability because the project is
> > not actively maintained and mainly depends on a single person. It is not
> > unmaintained either.
> > 
> > Due to such risks I preferred to rely on pytest for running tests, as I prefer
> > to depend on an ecosystem that has a *big* pool of maintainers.    
> > 
> > Do not take my remark as a proposal to switch to pytest, is only about risk
> > assessment. I am fully aware of how easy is to write impure unittests with
> > pytest, but so far I did not regret going this route.
> 
> At the risk of starting a tool comparison thread (which isn't my intention),
> it's worth noting that much of the reluctance to embrace pytest in the past has
> been due to its coupling of both a test runner and a test framework/library in
> the same tool. If I recall correctly, this pattern has existed before, in the
> form of 'nose', and the fate of that project has cast a long, dark shadow over
> similar projects. stestr may be "lightly staffed", but our consistent use of the
> unittest framework from stdlib across virtually all projects means we can easily
> switch it out for any other test runner than supports this protocol, including
> pytest, if we feel the need to in the future. Were pytest to be embraced, there
> is a significant concern that its use won't be restricted to merely the test
> runner aspect, which leaves us tightly coupled to that tool. You've touched on
> this above, but I feel it worth stating again for anyone reading this.

yep by the way you can use pytest as a runner today locally.
i do use it for executing test in the rare case i use an ide like pycharm to run test because
i need an interactive debugger that is more capbale the pdb.

im kind of surprised that trstr is still used at all since the move to stster was ment to be
done 3-4+ releases ago.

i actully kind of prefer pytest style of test but we have a lot of famiarliarty with the unittest framework
form the standard lib and losing that base of knolage would be harmful to our productivity and ablity to work
on different porjects. if its used as a test runner i think that would be ok provide we dont also use it
as a test framework. one of the gaps that woudl need to be adress is ensurint we can still generate teh same html
summaries which currently are based on the subunit? protofoal i belive whihc pytest does not use so we would need to make
suer it works with our existing tooling.

i dont think it realistic that pytest is going to die. its used way to hevally for that granted its only 55 on the top 100 downloaded package
over the last year on pypi but that still put it ahead of lxml(58) and sqlalchemy(71)
which we have no problem using, eventlets did not even make the list... https://hugovk.github.io/top-pypi-packages/.
its used by too many large projects to realistically die in the way its being implyed it might. the bigger risk form me
is mixing tests styles and ending up with test that can only run under pytest.

i would avocate for completeing the process of migrating everythign to stestr before considering moving to pytest or anything else.
if project do decided to adopt pytest instead i would sugess gating that and makeing sure or other tooling from jobs is updated to work with that
or we have an alternitve report generator we can use e.g. https://pypi.org/project/pytest-html/ i do think adopoting pytest however if iit was
done should be comunity wide rather then perproject hence why i think we should complete the current goal of moving to stestr first.


> 
> Cheers,
> Stephen
> 
> > I know that OpenStack historically loved to redo everything in house and
> > minimise involvement with other open source python libraries. There are pros
> > and cons on each approach but I personally prefer to bet on projects that are
> > thriving and that are unlikely to need me to fix framework problems myself.
> > 
> > Cheers,
> > Sorin
> > 
> > On Tue, 9 Feb 2021 at 17:59, Martin Kopec <mkopec at redhat.com> wrote:
> > > Hi everyone,
> > > 
> > > testr unit test runner (testrepository package [1]) hasn't been updated for
> > > years, therefore during Shanghai PTG [2] we came up with an initiative to
> > > migrate from testr to stestr (testr's successor) [3] unit test runner.
> > > Here is an etherpad which tracks the effort [4]. However as there is still
> > > quite a number of the projects which haven't migrated, we would like to
> > > kindly ask you for your help. If you are a maintainer of a project which is
> > > mentioned in the etherpad [4] and it's not crossed out yet, please migrate
> > > to stestr.
> > > 
> > > [1] https://pypi.org/project/testrepository/
> > > [2] https://etherpad.opendev.org/p/shanghai-ptg-qa
> > > [3] https://pypi.org/project/stestr/
> > > [4] https://etherpad.opendev.org/p/enkM4eeDHObSloTjPGAu
> > > 
> > > Have a nice day,
> > > 
> > > -- 
> > > Martin Kopec 
> > > Software Quality Engineer
> > > Red Hat EMEA
> > > 
>