On Sun, Nov 29, 2020 at 3:00 PM Miro Hrončok mhroncok@redhat.com wrote:
On 11/29/20 7:35 AM, Kalev Lember wrote:
On Sun, Nov 29, 2020 at 1:55 AM Miro Hrončok <mhroncok@redhat.com mailto:mhroncok@redhat.com> wrote:
On 11/28/20 10:06 PM, Ville-Pekka Vainio wrote: > Hi, > > I'm slowly working on reviving the Finnish spell-checking stack.
When
> working on the libvoikko package, I noticed the Python module now
has
> this in the file list: > > %if ! 0%{?flatpak} > %{python3_sitelib}/__pycache__/* > %endif > > Git blame takes me to this commit: >
https://src.fedoraproject.org/rpms/libvoikko/c/e1b9941462b82f208b814fc2f6e7f...
<
https://src.fedoraproject.org/rpms/libvoikko/c/e1b9941462b82f208b814fc2f6e7f...
> > Apparently Flatpak could not handle __pycache__ stuff about six
months ago.
> > According to the packaging guidelines I should be using something
like
> > %pycached %{python3_sitelib}/%{name}.py > > This macro is defined in /usr/lib/rpm/macros.d/macros.python3 and
it
> seems like it does not take the Flatpak issue into account. > Should I just leave those lines as they are? Should the %pycached > macro be improved? You should be able to use the %pycached macro and if that breaks
flatpaks, we
should amend that macro to support that instead of adding `%if !
0%{?flatpak}`
to individual spec files. The idea behind this macro is to be able
to do
changes in one place. However, it would help to know the reason why flatpaks don't have
bytecode
caches. This is the first time I've seen this mentioned. It will
require other
code to be adapted as well, for example %pyproject_save_files.
I believe this is because flatpaks are installed into /app, but the
python
bytecode compiler only does it for /usr.
brp-python-bytecompile has:
for python_libdir in `find "$RPM_BUILD_ROOT" -type d|grep -E
"/usr/lib(64)?/python[0-9].[0-9]$"`;
... which should use prefix instead of hardcoding /usr (or alternatively
scan
both /usr and /app).
Can do. However, one question: When we find code in /app/lib(64)/pythonX.Y, do we bytecompile with /usr/bin/pythonX.Y or /app/bin/pythonX.Y?
Awesome, thanks!
It depends: for python2.7 (gimp flatpak) we use python2.7 re-built for /app prefix (so it's bundled with the app's flatpak), but for regular python3 we just use the /usr-installed one that's part of the flatpak runtime (the runtime uses /usr prefix and app flatpaks use /app prefix).
Would it be possible to just use %__python2 and %__python3 macros for byte-compiling? These are always set correctly by the flatpak macros, no matter if the interpreter is in /app or /usr.
Kalev