Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix the test suite with pytest-cases #20

Closed
smarie opened this issue Apr 29, 2021 · 9 comments · Fixed by #25
Closed

Fix the test suite with pytest-cases #20

smarie opened this issue Apr 29, 2021 · 9 comments · Fixed by #25
Labels

Comments

@smarie
Copy link
Owner

smarie commented Apr 29, 2021

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

@smarie smarie added the enhancement New feature or request label Apr 29, 2021
@smarie
Copy link
Owner Author

smarie commented Apr 29, 2021

See smarie/python-pytest-cases#200

@smarie
Copy link
Owner Author

smarie commented May 4, 2021

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
Copy link

kloczek commented May 4, 2021

@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
Copy link
Owner Author

smarie commented May 5, 2021

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
Copy link
Owner Author

smarie commented May 5, 2021

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
Copy link

kloczek commented Jan 9, 2022

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
Copy link
Owner Author

smarie commented Jan 10, 2022

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
Copy link

kloczek commented Jan 10, 2022

No problem :)
Thank you to let me know.

@smarie
Copy link
Owner Author

smarie commented Feb 10, 2022

Thanks @kloczek for confirming that it works !

(you posted your confirmation message in the wrong place but I found it :) smarie/python-pytest-cases#200 (comment) )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants