I’m on Fedora 36, XFCE. I disabled the default XFCE window manager and installed Qtile. Qtile is not in DNF, so I installed Qtile using PIP(Python package manager). It installed Qtile to /.local/lib/python3.10/site-packages. Fedora 36 used Python 3.10 as seen in the path.
I upgraded Fedora to version 37. Fedora 37 bumped the Python version to 3.11. So when I logged in after the upgrade, Fedora could not find Qtile(as its now looking in /.local/lib/python3.11/site-packages). So my system was banjo’d(luckily I could still open a terminal and was able to PIP install Qtile again to the Python 3.11 folder).
Is there anything I could do to avoid this issue, to make sure Qtile is always installed for future upgrades(if Fedora 38 or 39 bump up the default Python version) or would it be something I just have to live with?
I strongly encourage you to consider using venv instead and that way you can keep python interpreters and dependencies like this separate from the system runtime. This is good practice for doing python development work in general:
If the developer of Qtile is able to get the package included in the fedora repo as an rpm then yes it would automatically be upgraded. If it is not in a compatible repo that can be upgraded by using dnf then probably not.
There are many python packages that can be installed on fedora. All you need to do to see that is to run dnf list python3-* and you can see the large number of python packages installed and/or available.
If using pip it is always advisable to install as a user and not using sudo (it seems you did that properly) or use a venv. The many pip packages may overwrite some system files and cause problems if the packages are installed system wide using sudo.
One advantage of a venv is it keeps the package within its own python version environment.
IIRC, it was packaged in Fedora at one time (and even got in a Fedora magazine article) but unfortunately dropped after becoming orphaned. If someone reading this wants to step up and help package/test it again, that would be awesome.
Thanks for the feedback. I only heard about COPR a few months ago. That probably would have been the best solution with hindsight(assuming the COPR version is kept up to date).
Yes I do the odd website with Python and I always use pipenv for those. I did have one website on my system at the time of my upgrade and that pipenv was borked after the upgrade also(I’m not sure why/ how that is possible. I’d have to dig deeper into the workings of pipenv. I assumed the env gets it’s own unique Python binary).
I didn’t want to install Qtile in a virtual env because I wasn’t sure if I’d have to activate that env each time I logged in(and I do need other env active when working on Python websites).
And I didn’t install Qtile with sudo(as Jeff suggested). If i did it wouldn’t have put Qtile in a /.local/ directory. It would have installed it in a shared folder other users could access.
Thanks again for the feedback both of you. Appreciate it.
I know it’s subjective and everybody will have their own opinion. But I reckon Qtile is better than i3 and i3 gets first class treatment in all the various distros. No worries anyway. Thanks again.
Sorry I implied you had used sudo. I have edited the post to reflect that I knew it was in ~/.local/.
It gets enough of the binaries and the site-packages to run as its own version even when the system binaries are updated. Any package installed in a venv will run in that venv when launched from that venv binary. For example, I have OctoPrint loaded and running in a venv.
I defined the venv as /home/user/Octoprint so launching it manually and running in the virtual env is as simple as /home/user/Octoprint/bin/octoprint and I have a service that launches it at boot from that venv
In a python script, you can set #!/path/to/venv/bin/python as the first line and it will pull everything from the venv. You can also start it by calling the interpreter in the venv /path/to/venv/bin/python qtile.... In a systemd service, I believe you’d want to do something like this:
Yeah, I did not mention that since most apps I install in a venv are smart enough to modify the startup script in that manner for me. Guess I better remember that if I install something that is not written to manage that for me during install.
