python-zipp
No description set
- Sources inherited from project devel:languages:python
- Devel package for openSUSE:Factory
-
19
derived packages
- Links to openSUSE:Factory / python-zipp
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout home:Tomcat42/python-zipp && cd $_ - Create Badge
Refresh
Refresh
Source Files (show unmerged sources)
| Filename | Size | Changed |
|---|---|---|
| _multibuild | 0000000053 53 Bytes | |
| python-zipp.changes | 0000008411 8.21 KB | |
| python-zipp.spec | 0000002429 2.37 KB | |
| zipp-3.18.1.tar.gz | 0000021220 20.7 KB |
Latest Revision
buildservice-autocommit
accepted
request 1160959
from
Factory Maintainer (factory-maintainer)
(revision 42)
Factory Maintainer (factory-maintainer)
(revision 42)
baserev update by copy to link target
Comments 8
Why is it still built on Leap 15.x although skip_python36 is 1?
The symbol in SLE-15 (and thus Leap 15.*) is
python3notpython36.With this package, I have the same problem as described here.
I looked at upstream and they already removed some Python 3.6 compatibility code: https://github.com/jaraco/zipp/commit/c0802277a1b9d799118751a4f032b495172ef1f5
Starting from CPython 3.6, dicts are ordered, although it’s part of the language specification only from Python 3.7. PyPy had ordered dicts for some longer time. So in practice, it won’t really make a difference. Of course, if more compatibility code is removed in the future, we’ll run into problems. Although not a perfect solution, we could copy the approach from https://build.opensuse.org/request/show/984778 for now.
What do you think?
If the test suite passes, I would agree, go for it. If necessary, add a conditional BR on python-ordereddict, we should have it somewhere (probably not in Factory)
python-ordereddict is for Python < 2.7, we will be fine without it. ;)
So I’ve checked that the current version of zipp works on Python 3.6. However, this has to be checked everytime we upgrade it. Would it be sufficient to hope that people check it on every upgrade? Alternatively, it could fix the required python metadata in the package if and only if Python == 3.6 and %version < 3.8.0. Then, on upgrade, build would fail on Python 3.6 until the check is updated, too. Is there a macro to do version comparisons?
That’s why I insist on running test suites whenever we can … then we have at least some automatic checking every time anything changes.
I agree that testing is important and should be done for each package.
However, the question is whether we consider running the test suite as sufficient or we still want people to manually check that no incompatibility was introduced. I think it wouldn’t be that unusual to rely on some implementation detail of a particular Python version without writing a test for it.
Running the test suite is probably the best (and only) thing we have, so yes, it probably have to be sufficient. If we find a problem, let's move it upstream and get more tests for it.