Hello Python RPM packagers,
based on some discussion in the "F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)" thread [0], I've drafted a macro that can help to test-import a Python module in %check when no other tests exist or are when they cannot be executed during build [1].
The semantics is quite simple:
%check %py3_check_import mymodule mymodule.submodule
When all listed modules are successfully imported, "nothing happens", when at lest one fails to import, the entire build fails. The above line is translated very-roughly to `python3 -c 'import mymodule, mymodule.submodule'` (see the implementation [0] for more accurate representation). Given the Python semantics, it is possible to use commas as module separators as well (but no parentheses).
The %buildroot's %pythn3_site{lib,arch} is added to PYTHONPATH.
The runtime dependencies are obviously needed for this to work, so they need to be manually BuildRequired or even better, generated in %generate_buildrequires via `%pyproject_buildrequires -r` to use this macro.
The macro can be used repeatedly when importing multiple modules at once is undesired (e.g. when only one module can be imported from the same Python interpreter):
%check %py3_check_import mymodule.either %py3_check_import mymodule.or
Before I merge this and backport to all Fedoras and EPELs, I'd like to know:
- Do you have better ideas for the macro name? - Do you have better ideas for the macro semantics?
[0] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... [1] https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99
Hi Miro,
Miro Hrončok mhroncok@redhat.com writes:
Hello Python RPM packagers,
based on some discussion in the "F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)" thread [0], I've drafted a macro that can help to test-import a Python module in %check when no other tests exist or are when they cannot be executed during build [1].
The semantics is quite simple:
%check %py3_check_import mymodule mymodule.submodule
When all listed modules are successfully imported, "nothing happens", when at lest one fails to import, the entire build fails. The above line is translated very-roughly to `python3 -c 'import mymodule, mymodule.submodule'` (see the implementation [0] for more accurate representation). Given the Python semantics, it is possible to use commas as module separators as well (but no parentheses).
The %buildroot's %pythn3_site{lib,arch} is added to PYTHONPATH.
The runtime dependencies are obviously needed for this to work, so they need to be manually BuildRequired or even better, generated in %generate_buildrequires via `%pyproject_buildrequires -r` to use this macro.
The macro can be used repeatedly when importing multiple modules at once is undesired (e.g. when only one module can be imported from the same Python interpreter):
%check %py3_check_import mymodule.either %py3_check_import mymodule.or
Before I merge this and backport to all Fedoras and EPELs, I'd like to know:
- Do you have better ideas for the macro name?
- Do you have better ideas for the macro semantics?
This looks pretty good imho. Would it somehow be possible for the macro to automatically try to import the module name from the generated python3.Ydist() provides? That would make the macro even more convenient to use and reduce any potential user error further.
Cheers,
Dan
On 28. 06. 21 22:25, Dan Čermák wrote:
Hi Miro,
Miro Hrončok mhroncok@redhat.com writes:
Hello Python RPM packagers,
based on some discussion in the "F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)" thread [0], I've drafted a macro that can help to test-import a Python module in %check when no other tests exist or are when they cannot be executed during build [1].
The semantics is quite simple:
%check %py3_check_import mymodule mymodule.submodule
...
This looks pretty good imho. Would it somehow be possible for the macro to automatically try to import the module name from the generated python3.Ydist() provides? That would make the macro even more convenient to use and reduce any potential user error further.
Honestly, I'd rather not do that. People already confuse "module names" (that's what you import) with "Python package names" (that's what you install from PyPI or what's provided as python3.Ydist()). And while this would make the macro slightly easier to use for the optimal case when those names are identical, it would only create more confusion when they are not.
In the future, we could extend it to automatically import modules found in the %buidlroot, but now I'd rather provide a simple tool where the packager needs to be explicit, than a very complex tool that does heuristics.
Miro Hrončok mhroncok@redhat.com writes:
On 28. 06. 21 22:25, Dan Čermák wrote:
Hi Miro,
Miro Hrončok mhroncok@redhat.com writes:
Hello Python RPM packagers,
based on some discussion in the "F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)" thread [0], I've drafted a macro that can help to test-import a Python module in %check when no other tests exist or are when they cannot be executed during build [1].
The semantics is quite simple:
%check %py3_check_import mymodule mymodule.submodule
...
This looks pretty good imho. Would it somehow be possible for the macro to automatically try to import the module name from the generated python3.Ydist() provides? That would make the macro even more convenient to use and reduce any potential user error further.
Honestly, I'd rather not do that. People already confuse "module names" (that's what you import) with "Python package names" (that's what you install from PyPI or what's provided as python3.Ydist()). And while this would make the macro slightly easier to use for the optimal case when those names are identical, it would only create more confusion when they are not.
In the future, we could extend it to automatically import modules found in the %buidlroot, but now I'd rather provide a simple tool where the packager needs to be explicit, than a very complex tool that does heuristics.
That makes sense & is probably the better approach initially. I have honestly no idea what could be improved here, so this looks more than fine by me :)
Cheers,
Dan
Probably silly idea, but there is already suggested `%{__nodejs} -e 'require("./")'` in Node.js guidelines, something similar was requested for rubygem- packages, is there chance to come with something more generic? E.g. having some BRP instead?
Vít
Dne 28. 06. 21 v 21:44 Miro Hrončok napsal(a):
Hello Python RPM packagers,
based on some discussion in the "F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)" thread [0], I've drafted a macro that can help to test-import a Python module in %check when no other tests exist or are when they cannot be executed during build [1].
The semantics is quite simple:
%check %py3_check_import mymodule mymodule.submodule
When all listed modules are successfully imported, "nothing happens", when at lest one fails to import, the entire build fails. The above line is translated very-roughly to `python3 -c 'import mymodule, mymodule.submodule'` (see the implementation [0] for more accurate representation). Given the Python semantics, it is possible to use commas as module separators as well (but no parentheses).
The %buildroot's %pythn3_site{lib,arch} is added to PYTHONPATH.
The runtime dependencies are obviously needed for this to work, so they need to be manually BuildRequired or even better, generated in %generate_buildrequires via `%pyproject_buildrequires -r` to use this macro.
The macro can be used repeatedly when importing multiple modules at once is undesired (e.g. when only one module can be imported from the same Python interpreter):
%check %py3_check_import mymodule.either %py3_check_import mymodule.or
Before I merge this and backport to all Fedoras and EPELs, I'd like to know:
- Do you have better ideas for the macro name? - Do you have better ideas for the macro semantics?
[0] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... [1] https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99
On 29. 06. 21 10:47, Vít Ondruch wrote:
Probably silly idea, but there is already suggested `%{__nodejs} -e 'require("./")'` in Node.js guidelines, something similar was requested for rubygem- packages, is there chance to come with something more generic? E.g. having some BRP instead?
That is indeed a nice idea to explore once everything else is done :)
packaging@lists.fedoraproject.org