Closed dcermak closed 1 year ago
@davidcassany We have a nasty problem, as rpm is a system package, it's python bindings are only available to the system-default python… (see https://pypi.org/project/rpm/). This unfortunately breaks our test matrix with different python versions :-/
Do you think it would be sufficient that we rely on the integration tests here? They run on Leap, Tumbleweed and SLE, so we should get some decent test coverage via that.
@davidcassany We have a nasty problem, as rpm is a system package, it's python bindings are only available to the system-default python… (see https://pypi.org/project/rpm/). This unfortunately breaks our test matrix with different python versions :-/
There isn't really any reason why python3-rpm.spec
couldn't be multipython FWICT, but for now that's what we have to work with...
@davidcassany We have a nasty problem, as rpm is a system package, it's python bindings are only available to the system-default python… (see https://pypi.org/project/rpm/). This unfortunately breaks our test matrix with different python versions :-/
Do you think it would be sufficient that we rely on the integration tests here? They run on Leap, Tumbleweed and SLE, so we should get some decent test coverage via that.
So you are suggesting to keep our current unit tests for a single python version and keep current integration tests for all versions?
I'm fine with that approach as long as we keep the unit tests for at least for a single python version. This is a pretty simple package and chances to hit issues caused by python divergences across pythons versions are low IMHO (any obvious mismatch should be caught by the integration tests AFAICT).
@davidcassany done. We will also have to adjust the branch protection settings (I can do that once we are all on board with this change)
cc @Vogtinator