The rpm places the module in the wrong directory on Fedora 35

[Poikilos]

An updated Fedora 35 runs Python 3.10, but the Sunflower RPM installs the module specifically to /usr/lib/python3.9/site-packages.

Actual behavior:

• When launched from the GUI, the application never appears.
• When launched from a fresh Terminal session, the following error appears:

$ sunflower 
Traceback (most recent call last):
  File "/usr/local/bin/sunflower", line 4, in <module>
    runpy.run_module('sunflower', run_name='__main__', alter_sys=True)
  File "/usr/lib64/python3.10/runpy.py", line 205, in run_module
    mod_name, mod_spec, code = _get_module_details(mod_name)
  File "/usr/lib64/python3.10/runpy.py", line 140, in _get_module_details
    raise error("No module named %s" % mod_name)
ImportError: No module named sunflower

The following workaround is confirmed to work:
sudo ln -s /usr/lib/python3.9/site-packages/sunflower /usr/lib/python3.10/site-packages/

Expected behavior:

The rpm may have to have scripting or a separate package for different Python versions.

[MeanEYE]

Hi. Thanks for reporting this. Unfortunately RPM distros don't have universal Python lib directory like Debian does /usr/lib/python3 instead of with minor version. This means I have to try and guess Python version during package build which leads to fragmentation unfortunately. So Fedora 35 is Python 3.10, previous version is Python 3.9, etc.

I tried finding a better solution but I failed. I simply don't know where to put this directory or how detect it during installation since RPM builder takes current python version in build time and that's where it ends up.

Solution to your problem is to build a package on your OS and then install it. I will be producing package myself, but I have to install Fedora 35 now as well. It's getting harder increasingly.

Am certain there's a simple solution but I was unable to find it. If you have any information on this, please let me know. I've spent embarrassing amount of time trying to fix this issue which is plaguing me for years now. I will leave this issue open as a reminder for next version. Hopefully a universal solution comes up.

[joshas]

How about building a Flatpak package #421 ? While I'm not a huge fan of installing additional runtimes for small applications, but most users would benefit from Flatpak, as it is easier to install and won't have issues on different distributions, as runtime is the same on every one. I think building Flatpak could be automated, so there will be less maintenance later, as updates could reach users very quickly after commit to main branch.

[MeanEYE]

I'll certainly look at solving that one. My love for flatpak died some time ago after I tried using it. Had nothing but issues with it and I didn't want to deal it on my personal projects as well. I have very limited free time to work on Sunflower as it is, dealing with Flatpak issues is last of things I want that time to be spent on.

That said need seems to be getting there so I'll have to look into it.

[oiiiiiiii]

@MeanEYE is there a guide somewhere on how to build this project? Or can you tell me what I have to do? I have the same problem.

[MeanEYE]

Building RPM or DEB package is done through make file. So it's simply make dist-rpm or similar. See make help. You will need PACKAGER environment variable so in summary it would be command like this:

PACKAGER="Your Name <[email protected]> make dist-rpm

[oiiiiiiii]

@MeanEYE thanks a lot, that worked! :)

[almereyda]

This issue continues to be of relevance on Fedora 38:

$ sunflower
Traceback (most recent call last):
  File "/usr/local/bin/sunflower", line 4, in <module>
    runpy.run_module('sunflower', run_name='__main__', alter_sys=True)
  File "<frozen runpy>", line 222, in run_module
  File "<frozen runpy>", line 142, in _get_module_details
ImportError: No module named sunflower

$ python --version        
Python 3.11.4

$ rg '^(NAME|VERSION)=' /etc/os-release
1:NAME="Fedora Linux"
2:VERSION="38 (Workstation Edition)"

How do other projects solve this question?

Maybe there is a way to do a matrix build accross currently supported revisions?

[Poikilos]

The core issue seems to be that:

1. building the executable "sunflower" file and setting it as executable is supposed to be done by the "setup.py" (setup.toml is recommended for Python 3) and the package should run setup.py rather than manually inserting the file that setup.py is supposed generate, that being "sunflower".
2. same for the "sunflower" subdirectory (module). Python itself should run a setup.py or use a setup.toml so that the "sunflower" package is installed to the site-packages directory it chooses, not a directory the package maintainer chooses.

Otherwise the install is not Pythonic, but rather is working around Python's predictable systems. The install method recommended by Python is: pip install sunflower where sunflower is the repo directory containing the sunflower module directory of the same name, as well as containing setup.toml alongside it (not in it).

If there is some limitation of RPM that makes the package maintainer have to choose where to put files, they could be placed in /usr/lib/sunflower (resulting in the module being /usr/lib/sunflower/sunflower and setup being /usr/lib/sunflower/setup.toml), and then the post-install script of the rpm would be pip install /usr/lib/sunflower. Even though the /usr/lib/sunflower dir would be completely unused from that point on (as pip install would copy the sunflower module and generate the sunflower file in the correct places automatically), this would be a workaround if RPM has limitations requiring hard-coded destinations. If temporary directories can be defined in the package itself rather than via scripting that would be another workaround (then the post-install script could be something like pip install /tmp/sunflower where that generates the sunflower executable file and copies the /tmp/sunflower/sunflower module to the correct place automatically).

[MeanEYE]

To be completely honest RPM is a mystery to me. Am a Debian user so building and testing packages is easily done but when it comes to RPM it seems that every distro that inherits the package manager decides to do something interesting. I would love to come up with a universal solution if there's one but I had no such luck.

Same thing goes with Python's setup.py. Whenever I tried to solve the problem of including static files or doing things the proper way I've ran into different explanation on how this should be done. If anyone has a better approach I would be more than happy to merge a PR.