Open vlad-sharpie opened 7 months ago
This was brought up in #574
Here is my comment I left there pertaining to this issue
The main issue I see is when looking at /etc/os-release it only shows the distro as Fedora rawhide. Is there anyway for the script to distinguish a standard Fedora install from a Silverblue install?
I found a solution, but it's not a "good" one and at least it seems to work. Install poetry, remove all references to cairo and Gobject, inside the .toml file remove all the references to the GUI and make sure to delete the poetry.lock file. A more permanent fix would be to separare the two packages and let the user decide if it actually wants the GTK interface.
EDIT: maybe just removing the gui stuff from the toml file is enough, I didn't test it
A more permanent fix would be to separare the two packages and let the user decide if it actually wants the GTK interface.
I kind-of agree with this. In future, can we go on with opt-in based design, handling GUI and CLI separately? This may in a way solve the dependency loophole for multiple users at once and might also decrease installation time (building wheels for PyGObject takes a while).
It's also very possible with our current design with poetry and this. In a way, we can group dependencies, moving GUI dependencies to other group and hence solving GUI installation dependency problems. In future, hence we can control the GUI installation with probable certain flag during installation, that can be used as a fallback in case of dependencies issue. (I haven't tested these yet as my exams are going on, but might test it soon whenever I get free!)
I have exactly the same issue and have not found a working solution, I am on bluefin based on fedora 39
Fedora 39 workstation is also suffering from similar install failure while generating the package metadata.
When "raise RuntimeError", it replys that "This does not appear to be a Git project"
A more permanent fix would be to separare the two packages and let the user decide if it actually wants the GTK interface.
I kind-of agree with this. In future, can we go on with opt-in based design, handling GUI and CLI separately? This may in a way solve the dependency loophole for multiple users at once and might also decrease installation time (building wheels for PyGObject takes a while).
It's also very possible with our current design with poetry and this. In a way, we can group dependencies, moving GUI dependencies to other group and hence solving GUI installation dependency problems. In future, hence we can control the GUI installation with probable certain flag during installation, that can be used as a fallback in case of dependencies issue. (I haven't tested these yet as my exams are going on, but might test it soon whenever I get free!)
Cant agree any more. I like the CLI version, its fast and clean! There is literally no need for me to install a bunch of things just for GUI, buggable and slooooow
EDIT: maybe just removing the gui stuff from the toml file is enough, I didn't test it
Can confirm that this works! I just commented out anything with PyGObject or about installing the GTK UI. Here's my working toml file:
pyproject.toml
EDIT: maybe just removing the gui stuff from the toml file is enough, I didn't test it
Can confirm that this works! I just commented out anything with PyGObject or about installing the GTK UI. Here's my working toml file:
pyproject.toml
@rootCircle is there any way to have or not to have these changes based on certain condition? If not, it might be a best idea to simply update Installing auto-cpufreq part of README and add section for Fedora Silverblue with this info ...
Maybe it can be done with either the extras or with the flag --without/--only, not too sure since I've never used poetry.
EDIT: maybe just removing the gui stuff from the toml file is enough, I didn't test it
Can confirm that this works! I just commented out anything with PyGObject or about installing the GTK UI. Here's my working toml file:
pyproject.toml
@rootCircle is there any way to have or not to have these changes based on certain condition? If not, it might be a best idea to simply update Installing auto-cpufreq part of README and add section for Fedora Silverblue with this info ...
I am not sure! I will try tinkering around a bit and will update, if it works out! I have been a fan of feature flags
in rust and I believe someone might have tried complementing that feature in Python too. So, it might be doable. But implementing this means when need to divide the tool into three parts
With either of cli or gui or both can be installed. This might require a bit of code restructuring in my opinion. I will check in and report!
Some Updates!
I tried the group dependency and extras in poetry, although they are perfect for installing deps, based on type of OS(controlled through flag in Installer script), but we can't control which entry points to include and exclude. Basically, what that means is, during installation, both auto-cpufreq and auto-cpufreq-gtk is created and then we need to manually remove auto-cpufreq-gtk based on requirements. This is kind of unintuitive, but the only solution I can find right now.
Suggestions are welcome!
In the auto-cpufreq-gtk.py script you can check for the packages presence and base the installation from there. It would not be perfect since if someone had already globally installed all the required packages would get the gtk one regardless, but it could work
In the auto-cpufreq-gtk.py script you can check for the packages presence and base the installation from there. It would not be perfect since if someone had already globally installed all the required packages would get the gtk one regardless, but it could work
This could be a potential solution, but there are few problems, here and there. Let's say a user wants to download only the CLI, the auto-cpufreq-gtk
entry point will still be visible for the user, although unusable. This might be annoying in my opinion, alternate we can do is instead of using auto-cpufreq-gtk
we can simply call auto-cpufreq --gui
and use it that way, making it a lot cleaner. This way we will only have a single entry point to the CLI
and we can overcome the limitations of poetry in controlling scripts based on flags.
Also, here is the pyproject.toml
, I could come with.
[tool.poetry]
name = "auto-cpufreq"
version = "2.2.0"
description = "Automatic CPU speed & power optimizer for Linux"
authors = ["Adnan Hodzic <adnan@hodzic.org>"]
license = "GPL-3.0-or-later"
readme = "README.md"
classifiers=[
"Development Status :: 5 - Production/Stable",
"Intended Audience :: Developers",
"Operating System :: POSIX :: Linux",
"Environment :: Console",
"Natural Language :: English"
]
keywords=["linux", "cpu", "speed", "power", "frequency", "turbo", "optimzier", "auto", "cpufreq"]
repository = "https://github.com/AdnanHodzic/auto-cpufreq"
documentation = "https://github.com/AdnanHodzic/auto-cpufreq#readme"
packages = [
{ include = "./auto_cpufreq" },
{ include = "./auto_cpufreq/gui" },
]
[tool.poetry.dependencies]
python = "^3.8"
psutil = "^5.9.8"
click = "^8.1.0"
distro = "^1.9.0"
requests = "^2.31.0"
PyGObject = {version= "^3.46.0", optional=true}
[tool.poetry.extras]
guix = ["PyGObject"]
[tool.poetry.group.dev.dependencies]
poetry = "^1.6.1"
[build-system]
requires = ["poetry-core>=1.0.0", "poetry-dynamic-versioning>=1.0.0,<2.0.0"]
build-backend = "poetry_dynamic_versioning.backend"
[tool.poetry.scripts]
auto-cpufreq = "auto_cpufreq.bin.auto_cpufreq:main"
auto-cpufreq-gtk = "auto_cpufreq.bin.auto_cpufreq_gtk:main"
# https://github.com/mtkennerly/poetry-dynamic-versioning
[tool.poetry-dynamic-versioning]
enable = true
vcs = "git"
format = "v{base}+{commit}"
# SideNote
# Regarding zip_safe = https://setuptools.pypa.io/en/latest/deprecated/zip_safe.html
EDIT: maybe just removing the gui stuff from the toml file is enough, I didn't test it
Can confirm that this works! I just commented out anything with PyGObject or about installing the GTK UI. Here's my working toml file:
pyproject.toml
This may be a stupid question, but upon running the install script with the modified pyproject.toml, it installs properly, but when I try to run it it errors with no "pyinotify" module. Installing that on silverblue/kinoite has proven to be a bit of trouble for me. (I'm a bit new to immutable fedora.)
EDIT: maybe just removing the gui stuff from the toml file is enough, I didn't test it
Can confirm that this works! I just commented out anything with PyGObject or about installing the GTK UI. Here's my working toml file:
pyproject.toml
This may be a stupid question, but upon running the install script with the modified pyproject.toml, it installs properly, but when I try to run it it errors with no "pyinotify" module. Installing that on silverblue/kinoite has proven to be a bit of trouble for me. (I'm a bit new to immutable fedora.)
Hey, I'm having the exact same issue on Fedora 40, have you found solution yet ?
It seems like what @rootCircle suggested is the solution.
However, unfortunately no one made any PR's regarding this so far.
Running
sudo ./auto-cpufreq-installer
errors on building dependencies, #394 shows it use to work so just wondering if this could get working again.