Re: Flatpak and __pycache__

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Nov 29, 2020 at 3:00 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
On 11/29/20 7:35 AM, Kalev Lember wrote:
> On Sun, Nov 29, 2020 at 1:55 AM Miro Hrončok <mhroncok@xxxxxxxxxx
> <mailto:mhroncok@xxxxxxxxxx>> 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/e1b9941462b82f208b814fc2f6e7f369bcda11a0?branch=master
>     <https://src.fedoraproject.org/rpms/libvoikko/c/e1b9941462b82f208b814fc2f6e7f369bcda11a0?branch=master>
>      >
>      > 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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux