Re: Packaging python3-*-devel subpackages
I agree with the proposal to include -devel packages when python3-devel
is installed. I think it makes sense, solves the problem with the
missing headers and won't affect most of the users.
Have a nice day.
Lumír
On 2/17/23 15:38, Miro Hrončok wrote:
Hello Pythonistats and packaging folks.
Tomáš (CCed) approached me today with an interesting question.
A Python package he is packaging into RPM (python3-rapidfuzz) installs
some development files (.h and .pxd).
Tomáš queried upstream about those files to figure out if they should
be installed or if they are only needed to build the package itself.
Upstream responded:
> rapidfuzz.h and __init__.pxd provide a capi for rapidfuzz, which
allows users
> to write their own similarity metrics in C/C++/Cython, which can be
called by
> rapidfuzz in a more performant way through this C-API.
> For this reason the header file should be part of the installation
as well.
OK, we want to ship them. Our packaging guidelines however say:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages
> Specifically, -devel packages must be used to contain files which are
> intended solely for development or needed only at build-time. This
is done to
> minimize the install footprint for users. There are some types of
files which
> almost always belong in a -devel package:
> - Header files...
So from our guidelines perspective, the files would go to
python3-rapidfuzz-devel. The way we packaged Python in 201x, this
would be the end of it.
However, in this decade with automatic Python BuildRequires, we could
easily end up in this situation:
1. a Python package lists rapidfuzz as a build requirement
2. %pyproject_buildrequires generates a dependency on
python3dist(rapidfuzz)
3. only python3-rapidfuzz is pulled
4. %build wants to use rapidfuzz.h
5. packager needs to manually BuildRequire python3-rapidfuzz-devel
To avoid (5), my suggestion was to add the following requirement to
python3-rapidfuzz:
Requires: (python3-rapidfuzz-devel%{?_isa} =
%{?epoch:%{epoch}:}%{version}-%{release} if python3-devel)
That way, application packages that pull in pytohn3-rapidfuzz as a
runtime dependency won't get it (we are minimizing the install
footprint for users), but users who build stuff (including RPM
packages) will get it (we make automatically generated dependencies
work as intended).
(Of course, users who have python3-devel installed for reasons other
than rapidfuxx will still get the files, but the assumption here is
that users who install -devel packages intent to /generally/ build
stuff.)
Is that a good suggestion? And if so, should it be a general
recommendation for such cases?
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Packaging python3-*-devel subpackages
Hello Pythonistats and packaging folks.
Tomáš (CCed) approached me today with an interesting question.
A Python package he is packaging into RPM (python3-rapidfuzz) installs some
development files (.h and .pxd).
Tomáš queried upstream about those files to figure out if they should be
installed or if they are only needed to build the package itself. Upstream
responded:
> rapidfuzz.h and __init__.pxd provide a capi for rapidfuzz, which allows users
> to write their own similarity metrics in C/C++/Cython, which can be called by
> rapidfuzz in a more performant way through this C-API.
> For this reason the header file should be part of the installation as well.
OK, we want to ship them. Our packaging guidelines however say:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages
> Specifically, -devel packages must be used to contain files which are
> intended solely for development or needed only at build-time. This is done to
> minimize the install footprint for users. There are some types of files which
> almost always belong in a -devel package:
> - Header files...
So from our guidelines perspective, the files would go to
python3-rapidfuzz-devel. The way we packaged Python in 201x, this would be the
end of it.
However, in this decade with automatic Python BuildRequires, we could easily
end up in this situation:
1. a Python package lists rapidfuzz as a build requirement
2. %pyproject_buildrequires generates a dependency on python3dist(rapidfuzz)
3. only python3-rapidfuzz is pulled
4. %build wants to use rapidfuzz.h
5. packager needs to manually BuildRequire python3-rapidfuzz-devel
To avoid (5), my suggestion was to add the following requirement to
python3-rapidfuzz:
Requires: (python3-rapidfuzz-devel%{?_isa} =
%{?epoch:%{epoch}:}%{version}-%{release} if python3-devel)
That way, application packages that pull in pytohn3-rapidfuzz as a runtime
dependency won't get it (we are minimizing the install footprint for users),
but users who build stuff (including RPM packages) will get it (we make
automatically generated dependencies work as intended).
(Of course, users who have python3-devel installed for reasons other than
rapidfuxx will still get the files, but the assumption here is that users who
install -devel packages intent to /generally/ build stuff.)
Is that a good suggestion? And if so, should it be a general recommendation for
such cases?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
