hyprwm / Hyprland

Hyprland is a highly customizable dynamic tiling Wayland compositor that doesn't sacrifice on its looks.

Home Page:https://hyprland.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[hyprpm] Use the most appropriate commit pin on no match

ItsDrike opened this issue · comments

Description

Current behavior

Currently, hyprpm is checking for an exact match on hyprland commit pins, and if there is no match, it will instead use the default branch.

This works more or less fine, however, there are people who have built hyprland from non-tagged commits, but neglected to update for a while, which has since resulted in plugin incompatibility.

Hyprland-git also sometimes contains accidental breaking changes for plugins, which soon get fixed, but for anyone who would attempt to build off of these versions, the plugin won't work for them, even if the plugin developer included a fix, because the fix has since been removed, as hyprland-git has addressed the issue already, and the plugins usually follow hyprland-git.

Proposed behavior

If hyprpm instead checked the commit pins by going over it's commit history from the current commit, checking if this commit exists in the pins, it would result in an overall better experience for plugin users, and would allow developers to permanently address issues on -git.

Because of the way hyprpm handles a commit pin (it's a simple git reset) the commit pin for a plugin doesn't just need to be the exact commit sha on the plugin pin side, it can also be a branch or a tag. This means it would still be possible for plugin devs to force latest versions to use their default branch, with a pin like ["<latest hyprland commit sha>", "HEAD"], which would always get picked up, even as hyprland makes newer commits, since the latest commit will be the closest in history.

I can't think of any reason not to do this, other than perhaps slightly slower times to check commit pins. Hyprpm is currently just getting the version from hyprctl, which would need to change to instead clone hyprland repo as it would require walking over all of the older commits. However, this clonning is already happening in update headers function, so it's probably not even that bad.

Also, git is a very powerful tool, so it very well might be possible to instead just get it to give you the number of commits since a certain commit, and only walk through the specified commit pins for each plugin, like it does now, picking the pin with least amount of commits since value. If this is possible with git, it would also allow people to use tags instead of commit shas even on the hyprland's side of the commit pin, which would also result in much cleaner commit pins, like ["v0.39.0", "v0.39.0"].

The only thing this would change for the plugin devs will be the need to declare that they want their latest version (HEAD) to be used with the latest hyprland-git, by adding that extra commit pin, and updating it as new releases come out, setting it to the next commit right after that release, as otherwise, the last stable commit pin will be used on -git versions. Although, if it would be possible to get git to give you that amount of commits, people could just do a pin like: ["HEAD", "HEAD"], perhaps this could even be the default, unless "HEAD" pin is manually specified, to avoid breaking changes for plugin devs.