https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_provides
Using a fictional module named "example", the subpackage containing the Python 3 version must provide python3-example.
I've just realized that this rule is not really followed in Fedora and it is probably too strict.
Several examples:
Those are just the couple packages I know. An automated check would show that there are possibly hundreds more.
Does the rule make sense as a must? If so, should we simply automated it (seems to be fairly trivial)?
Should modules starting with _ be excluded from this rule?
_
I think the rule should be weakened. Also, we should clarify what "module" means in this context. I usually say something like "importable module" to make this clear. Actually, it seems to me that the rule only makes sense for modules that are intended to be imported in other code. Notice that most of the examples above are internal implementation details, and for the others providing python3-foo would make sense. Also, "example" is a confusing example. So I suggest changing to:
For any module foo intended to be used in Python 3 with import foo, the package that includes it should provide python3-foo. This is of course always the case if the subpackage is named python3-foo (as in the examples below). If the subpackage has some other name, then Provides: python3-foo should be added explicitly (along with %python_provide python3-foo, see below).
foo
import foo
python3-foo
Provides: python3-foo
%python_provide python3-foo
So to follow such rule, given the given examples, we should add provides for python3-pkg_resources, python3-bs4, python3-rest_framework (+possibly python3-fedpkg if that's usable in that way, not sure). That makes sense.
Using a fictional module named "example"
I find that language confusing, as it is unclear whether "example" is also the PyPI name or not in that example. If it is intending to be "top level module", it should say so, and can be derived from dist-info/egg-info "top_level.txt", and the example name should be something which is unlikely to be the PyPI name.
It is actually quite useful to catch these before file conflicts, and file conflicts do not catch case when there are the same name is in lib and lib64 (I cant think of one offhand), and also doesnt catch prettytable.py vs prettytable/__init__.py (which is PrettyTable vs the main living fork of it PTable, which isnt API backwards compatible).
prettytable.py
prettytable/__init__.py
There are lots of _*
_*
> echo $(ls -1 /usr/lib64/python3.8/site-packages/_*.so | xargs -n 1 basename | cut -d '.' -f 1) _brotli _cbor2 _cffi_backend _cproton _cracklib _dbus_bindings _dbus_glib_bindings _distorm3 _fastcluster _icu _ldap _line_profiler _ped _portaudio _pycdio _pygit2 _pyiso9660 _pylibmc _pyo64 _pyo _py_pastream _rcssmin _re2 _rjsmin _ruamel_yaml _sane _sass _scandir _scrypt _smbc _solv _tagpy _tevent _ubjson _yaml _yappi _ycp
Don't forget python3-turtle (which would be great; it's just waiting for someone (me) to do it) and python3-math & co, which I'd love to hear your opinion on. (Maybe this would be better discussed at Python SIG than here, though)
python3-turtle
python3-math
It is actually quite useful to catch these before file conflicts
I don't think Requires will catch conflicts. I'd keep the python3-* namespace friendly to humans (i.e. users of dnf install). It's already overloaded enough. If we want to generate provides for top-level modules automatically and reliably, it could be something like python3module(*).
python3-*
dnf install
python3module(*)
Metadata Update from @churchyard: - Issue assigned to churchyard
Included in https://pagure.io/packaging-committee/pull-request/1011
Commit 9521a7a fixes this issue
Login to comment on this ticket.