feat: use uv to manage dependencies

[ZeyadMoustafaKamal]

closes #1017

As mentioned in #1017 many users have reported that they had a problem with the installer and basically creating a virtual environment will fix everything. We will use uv since it's the new way for how stuff works in python.

what we will do

• Modify the installer to install uv along with the other tools. And also creating the virtual environment itself. It should be in $XDG_STATE_DIR.
• Add a requirements.in file that contains dependencies.
• Install all needed dependencies.
• Modify all scripts to use the new python interpreter.
• Finally add a documentation that should explain how to deal with the new thing.

[ZeyadMoustafaKamal]

@clsty For this part

dots-hyprland/install.sh

Lines 136 to 143 in 41520ae

	case $SKIP_PYMYC_AUR in
	true) sleep 0;;
	*)
	pymycinstallflags=""
	$ask && showfun install-local-pkgbuild || pymycinstallflags="$pymycinstallflags --noconfirm"
	v install-local-pkgbuild "./arch-packages/illogical-impulse-pymyc-aur" "$pymycinstallflags"
	;;
	esac

As you can see. All packages in the mentioned PKGBUILD will be installed by uv except for grandience. Because it doesn't exists in the python package registry and the repo doesn't have a setup.py or a pyproject.toml. So we will leave it for yay. But as the problem mentioned here will no longer be an issue because we are installing everything in a virtual environment I think that we should basically remove this part. Is there anything that would force us to keep this part ?

[clsty]

Because it doesn't exists in the python package registry and the repo doesn't have a setup.py or a pyproject.toml. So we will leave it for yay.

Because that some issues are related to gradience too, I hope we can remove the use of yay for gradience.

setup.py or pyproject.toml is not existed, however, maybe(?) you can fork the gradience repo and create the required files by understanding and converting manually its provided installation process which uses meson:

• https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=gradience
• https://github.com/GradienceTeam/Gradience/blob/main/meson.build

I'm not sure whether this method will work. But we'd better avoid yay on gradience anyway.

But as the problem mentioned here will no longer be an issue because we are installing everything in a virtual environment I think that we should basically remove this part. Is there anything that would force us to keep this part ?

We need a gradience as gradience-cli is used here, which is the only reason. The part of this bash script you quoted is not necessary and should be removed once gradience is available using an alternative installation process, such as using uv.

[ZeyadMoustafaKamal]

setup.py or pyproject.toml is not existed, however, maybe(?) you can fork the gradience repo and create the required files by understanding and converting manually its provided installation process which uses meson:

Yeah I think that I will give it a try.

[ZeyadMoustafaKamal]

@clsty Finally I got gradience to work in a fresh arch install inside a virtual environment. I didn't fully test it, I just typed gradience-cli --help and it worked. As I am not sure what this is doing in the first place. So I would like that you go and test it yourself. Go to my forked repo and clone the branch I am working on in a fresh arch installation. And make sure that you have uv, git, and meson installed and then run these commands in the root directory of gradience

uv venv --prompt .venv -p 3.12
source .venv/bin/activate
bash install_deps.sh
uv pip install -r requirements.txt
meson setup build --prefix=$VIRTUAL_ENV
meson compile -C build
meson install -C build

Also you may get some error when you run the meson setup command. If you got it then just rm the build directory and then try again.

Then to run gradience-cli use this command

GSETTINGS_SCHEMA_DIR=$VIRTUAL_ENV/share/glib-2.0/schemas gradience-cli

You can export it as an environment variable or we might move the files there to the global path where gradience (or glib) searches to schemas by default. I would recommend the first approach as we want to isolate everything.

[clsty]

I do not have enough space for a fresh arch install currently so I just did a quick test on my own platform. It stuck here:

❯ uv pip install -r requirements.txt
  × No solution found when resolving dependencies:
  ╰─▶ Because pyjobject was not found in the package registry and you require pyjobject, we can
      conclude that your requirements are unsatisfiable.

As I am not sure what this is doing in the first place.

As I mentioned above, gradience-cli is used in this file. Specifically, when you press Super+Ctrl+T, you are prompted to select a wallpaper and then gradience-cli will be involved to generate a color scheme accordingly. Keybinding is defined in .config/hypr/hyprland/keybinds.conf as:

bind = Ctrl+Super, T, exec, ~/.config/ags/scripts/color_generation/switchwall.sh # Change wallpaper

And specifically gradience is only used to generate colorscheme for gtk:

apply_gtk() { # Using gradience-cli
    usegradience=$(sed -n '4p' "$STATE_DIR/user/colormode.txt")
    if [[ "$usegradience" = "nogradience" ]]; then
        rm "$XDG_CONFIG_HOME/gtk-3.0/gtk.css"
        rm "$XDG_CONFIG_HOME/gtk-4.0/gtk.css"
        return
    fi

    # Copy template
    mkdir -p "$CACHE_DIR"/user/generated/gradience
    cp "scripts/templates/gradience/preset.json" "$CACHE_DIR"/user/generated/gradience/preset.json

    # Apply colors
    for i in "${!colorlist[@]}"; do
        sed -i "s/{{ ${colorlist[$i]} }}/${colorvalues[$i]}/g" "$CACHE_DIR"/user/generated/gradience/preset.json
    done

    mkdir -p "$XDG_CONFIG_HOME/presets" # create gradience presets folder
    gradience-cli apply -p "$CACHE_DIR"/user/generated/gradience/preset.json --gtk both

    # And set GTK theme manually as Gradience defaults to light adw-gtk3
    # (which is unreadable when broken when you use dark mode)
    lightdark=$(get_light_dark)
    if [ "$lightdark" = "light" ]; then
        gsettings set org.gnome.desktop.interface gtk-theme 'adw-gtk3'
    else
        gsettings set org.gnome.desktop.interface gtk-theme adw-gtk3-dark
    fi
}

So, how to test? Let me provide a tip (please adjust it as you like): You may edit ~/.config/ags/scripts/color_generation/applycolor.sh and modify the

    gradience-cli apply -p "$CACHE_DIR"/user/generated/gradience/preset.json --gtk both

to (fill in the VIRTUAL_ENV value manually)

    date > /tmp/gradience.log
    export VIRTUAL_ENV=
    GSETTINGS_SCHEMA_DIR=$VIRTUAL_ENV/share/glib-2.0/schemas gradience-cli apply -p "$CACHE_DIR"/user/generated/gradience/preset.json --gtk both >> /tmp/gradience.log 2>&1

And use Super+Ctrl+T to switch a wallpaper. When gradience-cli not exists, the log file /tmp/gradience.log will have "command not found" thingy.

[ZeyadMoustafaKamal]

OK I think that we are reaching to a good point here. I have modified the install script to install all needed libraries in a virtual environment. And now all I need is to test it which is what I am doing right now. Also I have fixed the gradience issue you have told me about, you may try it again now.

As you can see in some files like this that has a shebang. Like do we really need it ? It's kinda hard and problematic to use the new python interpreter. Like it should exists in ~/.local/state/ags/.venv/bin/python and I can't point out to that path in the shebang. The only way I can fix this is by using a relative path in the shebang. Which is a problem since we should execute the files from specific directory and this will cause tons of problems. Or we can create a wrapper script to fix this. Or we might just not use a shebang in the first place. I don't see any sort of benefit from using the shebang in this situation. So why not remove it ? what you think ?

[clsty]

According to blog post and document, it's possible to point out a path like ~/.local/state/ags/.venv/bin/python in shebang, using a little trick. Firstly make sure that global environment variable ILLOGICAL_IMPULSE_VIRTUAL_ENV=$HOME/.local/state/ags/.venv exists, e.g. for hyprland config:

env = ILLOGICAL_IMPULSE_VIRTUAL_ENV, ~/.local/state/ags/.venv

and then as the shebang (Edit myscript.py to the script filename) :

#!/usr/bin/env -S\_/bin/sh\_-xc\_"exec\_\$ILLOGICAL_IMPULSE_VIRTUAL_ENV/bin/python\_-E\_"\$0"\_"\$@""$ ./myscript.py

(Other maybe related link: stackoverflow question)

---

Or we might just not use a shebang in the first place. I don't see any sort of benefit from using the shebang in this situation. So why not remove it ? what you think ?

Well, if you are about to remove shebang, it means that you need to modify all the codes that have involved the scripts, to use the virtual environment instead, right? For example in ~/.config/ags/modules/sideright/quicktoggles.js:

215:        if (self.attribute.enabled) Utils.execAsync(['bash', '-c', `pidof wayland-idle-inhibitor.py || ${App.configDir}/scripts/wayland-idle-inhibitor.py`]).catch(print)
216:        else Utils.execAsync('pkill -f wayland-idle-inhibitor.py').catch(print);
221:        self.attribute.enabled = !!exec('pidof wayland-idle-inhibitor.py');

See, it's not that easy, right? pidof wayland-idle-inhibitor.py and pkill -f wayland-idle-inhibitor.py may not work unless you are executing wayland-idle-inhibitor.py directly from shell, i.e. using shebang.

I'd rather just modify a single shebang in wayland-idle-inhibitor.py instead:

#!/usr/bin/env -S\_/bin/sh\_-xc\_"exec\_\$ILLOGICAL_IMPULSE_VIRTUAL_ENV/bin/python\_-E\_"\$0"\_"\$@""$ ./wayland-idle-inhibitor.py

[ZeyadMoustafaKamal]

OK I finished everything in my local machine and also I have installed it in a fresh arch installation (I hope that you can try it) I only have one problem, ags is not working for some reason. I have pkilled it and ran it again and this is all I am getting. I will push changes right now so you can try it and reproduce the problem. Like maybe the way I am creating the VM is the problem ?

[clsty]

Oh, I forgot to tell you that I've done a quick test and it seems good but just need some modifications as mentioned above. Also the new shebangs will fix the ags error (json parse error thingy).

After that it's very likely I'll merge this PR, if things go as expected.

[clsty]

Well, looks good. I'll merge it now. Some minor modifications will be done by me later.

Thanks for your contribution. Nice job!

[ZeyadMoustafaKamal]

OK thanks for these words.

[ZeyadMoustafaKamal]

Also I will do the documentation tomorrow. I was about to forget about it.

[clsty]

Also I will do the documentation tomorrow. I was about to forget about it.

Welcome. Take your time though, no hurry.

---

And for the fork of gradience, it seems that the final result only contains modification on requirements.txt, as shown here. I'm not sure whether this patch is necessary but anyway I've copied this repo to my account here, so that you're free to delete that fork now. @ZeyadMoustafaKamal

And for @end-4 , since this is your project in the end, I recommend you to fork or copy the repo to your account, so that I can modify the URL in install script to the repo under your account.
(Even if no patch is actually needed, the original Gradience repo is archived and may probably be deleted one day.)

---

@end-4 A breaking change is now involved: you'll need to set environment variable $ILLOGICAL_IMPULSE_VIRTUAL_ENV to ~/.local/state/ags/.venv, or AGS config will not work.

I've done adding notice in install.sh. Hope users would notice that after updating:

printf "\n\e[31m[$0]: !! Important !! : Please ensure environment variable \e[0m $ILLOGICAL_IMPULSE_VIRTUAL_ENV \e[31m is set to proper value (by default "~/.local/state/ags/.venv"), or AGS config will not work. We have already provided this configuration in ~/.config/hypr/hyprland/env.conf, but you need to ensure it is included in hyprland.conf, and also a restart is needed for applying it.\e[0m\n"

[end-4]

Thanks
@clsty, I see you sent me a repo transfer request. It's invalid, so I forked it and it's now available at end-4/ii-gradience. I also sent a collaborator invite for that repo

[ZeyadMoustafaKamal]

OK I still didn't create the setup.py because I took a a lot of time to figure out how to get meson to work so I decided that I will just make something that just works and then I will create setup.py in the future. And if I found that meson causes many problems I will edit the files that depends on meson so we don't need it anymore (we can do this actually). I will still need to learn about how to make a python package so just don't expect this in the near future.