#965 Python module named "example" must provide python3-example?
Closed: Fixed 2 years ago by churchyard. Opened 2 years ago by churchyard.

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:

  • python3-pytest does not provide python3-_pytest
  • python3-libxml2 does not provide python3-libxml2mod and python3-drv_libxml2
  • python3-gdal does not provide python3-gdalconst and python3-gdalnumeric
  • python3-setuptools does not provide python3-pkg_resources
  • python3-beautifulsoup4 does not provide python3-bs4
  • copr-cli does not provide python3-copr_cli
  • python3-koji does not provide python3-koji_cli
  • fedpkg does not provide python3-fedpkg
  • python3-uranium does not provide python3-UM
  • python3-django-rest-framework does not provide python3-rest_framework
  • autojump does not provide python3-autojump_data, python3-autojump_match and python3-autojump_utils
  • python3-black does not provide python3-_black_version, python3-blib2to3 and python3-blackd

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).

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).

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

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.

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)

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(*).

Metadata Update from @churchyard:
- Issue assigned to churchyard

2 years ago

Login to comment on this ticket.

Metadata
Related Pull Requests
  • #1011 Merged 2 years ago