Fix the test suite with pytest-cases

[smarie]

Tests use the old v1 API of pytest-cases, which were deprecated in version 2 and dropped in version 3

[smarie]

See smarie/python-pytest-cases#200

[smarie]

Two ways to solve this:

• extremely easy: simply add a version boundary to the test requirement on pytest-cases, probably pytest-cases<3 should work. Mod should be done here
• harder: update the test suite to use the latest pytest cases

@kloczek do both solutions work for you ? Just to know, since you were the one to report this.

[kloczek]

@kloczek do both solutions work for you ? Just to know, since you were the one to report this.

I think that caping from the top would be always driving to more and more build conflicst.
IMO proper solution is into direction of require some exact minimum versions of some components in build env and if something is wront like for example with pytest-cases that should be fixed in that module and than python-decopatch should require some minuim exact version of the pytest-cases. Only that way opens possibility to fix some issues in other modules.
If something is wrong in current test suite those failing units is possible to disable temporary and start working on those which needs to be fixed .. one by one.

Above may be not accurate from pure deveolopment point of view however I'm representin poit of view of those people who are packaging software and are lookimg from very broad view of literally ALL packages in typical distribution.

So again: caping from top is always kind of freezing status quo )wit all godd and bad things) and blocks changes around.

[smarie]

I still have trouble understanding what is so special in packaging RPMs. Is this because as opposed to standard python environments, you are trying to make sure that ALL rpms work together whatever the versions ? If so, the expectation is much higher than the one of a python user - typically a python user would create one venv (or virtualenv or conda env) for each project, and install inside this env only the packages required. Usually this subset is small and consistent enough for libs to work together, since lib maintainers try to ensure compliance with their ecosystem of reference.

Another way to put this, is that if the objective is to package an RPM for an application (not a library, an application: either a commandline, or a GUI, etc.), then I would recommend to create a "packaged distribution" for this application (py2exe, pyinstaller, cx_Freeze, etc) instead of trying to package each library required as a separate RPM and hoping that linux users will be able to make sure their env can continue to be stable and working as time goes on. This objective is definitely out of reach, any python user would confirm it.

[smarie]

Now to come back to my question, to be more precise: for the concrete project that is currently failing for you, will it work that I simply put an upper version boundary ? Of course I will end up migrating the test suite to pytest cases 3, sooner or later.

[kloczek]

I still have trouble understanding what is so special in packaging RPMs

Testing is very important. Wnen on packagin package A is executed test suite it is not only about exactly that package but all other components involved in testing. Ergo: more test suite -> higher probablity that something on interraction A with resto of the distribution will ba carched.

Usually exact projects maintainers are interested only own part. Forming distrinution I'm interested more about consistency of whole set of the packages.

Going back to the subject ..
So there is no solition when pytest-cases > 3.0 is used?

[smarie]

I'll have to update the test suite, it may take some time unfortunately as it is quite complex. Sorry @kloczek you'll have to wait again for some time.. (same for pytest-harvest and pytest-steps, I saw your messages - unfortunately my bandwidth is fairly limited on the open source side.)

I'll let you know when I do this

[kloczek]

No problem :)
Thank you to let me know.