On 26. 05. 22 17:13, Owen Taylor wrote:
> - Why is Python itself not installed in the /app prefix?
> - Where and how is pip install invoked?
The way that Flatpaks work is that there are *two* filesystem images, one
mounted on /usr and one mounted on /app. The image mounted on /usr is called
the "runtime" and contains libraries and other files shared between different
applications. In Fedora, this is made out of standard distribution packages -
glibc, libjpeg, and so forth. It also contains Python 3 and some modules.
The filesystem image at /app contains packages specific to a specific
application - the application itself and libraries. In Fedora, we create the
/app filesystem by rebuilding packages inside a module that is configured to
have a special RPM macros package installed in the buildroot -
https://src.fedoraproject.org/rpms/flatpak-rpm-macros/tree/f36
<https://src.fedoraproject.org/rpms/flatpak-rpm-macros/tree/f36> (installed at
/etc/rpm/macros.flatpak so that it has higher priority than the macros from
/usr/lib/rpm)
(The advantage of this split over the docker layer system is that applications
don't need to be rebuilt every time the base layer is updated.)
macros.flatpak redefines %_prefix to /app, and then does various more and less
hacky things to make that actual work within the Fedora RPM ecosystem - in
particular for Python, it overrides
%python3_sitelib and %python3_sitearch. The distutils.cfg I mentioned is
installed from the same package. This combination worked pretty well for F35
for Python.
pip install is being invoked is by %pyproject_install or %py_install_wheel out
of an RPM build - the particular breakage that triggered this investigation was
the Python bindings for zxing-cpp , but I think it would apply to pretty much
anything that has moved to the %pyproject macros.
I have a followup question about this approach.
Consider I want to build 2 (or more) Python packages into /app because my
Flatpak needs multiple libraries specific to my application.
For simplicity, let's assume the following dependency chain.
myapp -> python3-higher-level-lib -> python3-lower-level-lib
The build chain starts with python-lower-level-lib component. It set's %_prefix
to /app and installs everything to %{python3_stielib} which is in /app. Python
itself uses the /usr prefix, but we pass --prefix explicitly, so it works, the
resulting python3-lower-level-lib package contains everything in /app.
The build chain proceeds with python-higher-level-lib. During the build
python3-lower-level-lib is BuildRequired as it is required to run the %check
section. In the %check section, tests are executed and they want to import a
Python module from python3-lower-level-lib -- hewer, /app/.../site-pacakges is
not on sys.path and the %check fails.
How is the second situation solved? I've seen slightly horrifying things like
this in some specfiles:
%if ! 0%{?flatpak}
%check
make test ...
%endif
Was that because of this problem?
--
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 on the list, report it:
https://pagure.io/fedora-infrastructure
