-
Notifications
You must be signed in to change notification settings - Fork 4
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
Comments
Two ways to solve this:
@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. 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. |
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 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. |
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. |
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 .. |
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 |
No problem :) |
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) ) |
Tests use the old v1 API of pytest-cases, which were deprecated in version 2 and dropped in version 3
The text was updated successfully, but these errors were encountered: