-
Notifications
You must be signed in to change notification settings - Fork 556
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shelling out to pip during tests is problematic #2950
Comments
Thanks for raising this. In PyMuPDF the list of required test packages is currently available in [It's a shame that pytest doesn't allow specification of required packages in pytest.ini.] I'll have a look at adding a page to the docs with information for packagers; i'll leave this issue open for now and request a review here when i have something ready. Regarding use of system fonts, i'll defer to @JorjMcKie. |
MuuPDF, and hence neither PyMuPDF accesses system fonts of the respective platform. All fonts must either be built into the (MuPDF) binary, or provided when needed via either separate font files or in-memory binaries. Package pymupdf-fonts - if installed - provides certain selected fonts in-memory via its own methods - which is required in exactly this way for some PyMuPDF functions, specifically when using the Story feature. |
Please see new discussion about draft documentation for Linux system installs: #2977 |
Thanks for clarifying the use of fonts in pymupdf-fonts. |
In my tree i have removed the So tests should now work offline as long as the specified packages are pre-installed. |
Instead have added missing flake8 to scripts/gh_release.py:test_packages, so all required packages will already be available, e.g. when tests are run by `scripts/test.py`. This addresses pymupdf#2950 "Shelling out to pip during tests is problematic".
Instead have added missing flake8 to scripts/gh_release.py:test_packages, so all required packages will already be available, e.g. when tests are run by `scripts/test.py`. This addresses #2950 "Shelling out to pip during tests is problematic".
MuPDF (and hence PyMuPDF) do not access the system fonts of the respective machine because there is no standard based on which fonts can be assumed to be available. Certainly not across different operating systems, but also not even within one platform like Windows or Linux. So, MuPDF is providing function hooks that can be used by an installation / package providers to present a defined set of system fonts to MuPDF's algorithms.
... and void fz_install_load_system_font_funcs(fz_context *ctx,
fz_load_system_font_fn *f,
fz_load_system_cjk_font_fn *f_cjk,
fz_load_system_fallback_font_fn *f_fallback); an installation can make sure that MuPDF becomes aware of local fonts and includes them in its lookup algorithms. In PyMuPDF, a number of fonts are always available because they are compiled with the MuPDF binary (e.g. the Base-14 fonts, the "Droid Sans Fallback Regular" font for CJK and a few select other fonts like some Noto). Package pymupdf-fonts contains a dozen more fonts independent from the above, which the authors have come across over time, based on whatever motivations. This package is a convenient way to make available fonts to PyMuPDF without the need to re-compile anything or enlarging PyMuPDF's binaries and not even the memory footprint of PyMuPDF applications. |
Marking this as fixed in next release, because we no longer run The font problem remains, but that should really be in a separate issue. |
This is fixed in release candidate 1.23.9rc2; see: #2996 |
Fixed in 1.23.9. |
Description of the bug
Hi! 👋
While trying to package 1.23.8 for Arch Linux I ran into an issue with a new test:
It appears during test run the test shells out to calling pip to install pymupdf-fonts.
This is problematic, as for packaging purposes we want to know what is required up front and actually be able to disable internet access during build and test run.
If pymupdf-fonts is a test requirement it should be noted as such, and not be installed on the fly, as that arbitrarely alters the test environment.
Relatedly, why are fonts not loaded via system integration? Downstream distributions usually package all sorts of fonts and there is usually no need to bundle them in this special way (and using something generic would allow using all sorts of fonts and not just the bundled ones).
How to reproduce the bug
The build script for the previous version can be found here:
https://gitlab.archlinux.org/archlinux/packaging/packages/python-pymupdf/-/blob/07162b38e509ca0d9f107af94af4f88e74faa887/PKGBUILD
PyMuPDF version
1.23.8
Operating system
Linux
Python version
3.11
The text was updated successfully, but these errors were encountered: