same hyprland version for all plugins in nix

[luiswirth]

In the build instructions for nix in the README, there is this note on making sure that the hyprland versions are the same.

inputs.hyprland = {
      url = "git+https://github.com/hyprwm/Hyprland?submodules=1";
      # To make sure we run the same version of hyprland that the plugin was built against
      follows = "hyprland-virtual-desktops/hyprland"; 
};

How would one handle this with multiple plugins?

Is this a good approach?

hyprland = {
  url = "git+https://github.com/hyprwm/Hyprland?submodules=1";
  follows = "hyprland-virtual-desktops/hyprland";
};
hy3 = {
  url = "github:outfoxxed/hy3";
  inputs.hyprland.follows = "hyprland-virtual-desktops/hyprland";
};
hyprland-virtual-desktops = {
  url = "github:levnikmyskin/hyprland-virtual-desktops";
};

In my understanding, the correct thing todo, would be to use the newest hyprland version that is supported by ALL plugins. So the minimum of the the various input hyprlands of the plugins.

[luiswirth]

Doesn't this approach of setting the hyprland follows destroy the hyprland cachix? It seems that upon switching the configuration, everything gets build locally on my machine, instead of fetching the cached binaries... That's unacceptable for me :(

[luiswirth]

Is this a good method? This at least doesn't invalidate the hyprland cache, by swapping the dependence (plugins follow main hyprland, not the other way around).

hyprland.url = "git+https://github.com/hyprwm/Hyprland?submodules=1&ref=refs/tags/v0.40.0";
hy3 = {
  url = "github:outfoxxed/hy3/hl0.40.0";
  inputs.hyprland.follows = "hyprland";
};
hyprland-virtual-desktops = {
  url = "github:levnikmyskin/hyprland-virtual-desktops";
  inputs.hyprland.follows = "hyprland";
};

Without tagging release v40, I would get a build failure.

[levnikmyskin]

@wiillou would you check this?

[wiillou]

it shouldn't stop the hyprland cachix from working. I'll do some research when i get home.

[luiswirth]

also creating tags for the different hyprland versions, might be good move

[wiillou]

i agree, would make things a bit more coherent

[adam-neeley]

Yes, I believe you are correct. The instructions for installing on NixOS might want to say:

hyprland.url = "git+https://github.com/hyprwm/Hyprland?submodules=1";

hyprland-virtual-desktops = {
  url = "github:levnikmyskin/hyprland-virtual-desktops";
  inputs.hyprland.follows = "hyprland";
};

This works for me at least.

[levnikmyskin]

Again, I don't know much about Nix, but definitely Hyprland submodules are necessary to compile hyprland itself

[adam-neeley]

I agree. The submodules are included by the url specified in inputs.hyprland.url. There is also a Nix way, but the github get request is more concise. I believe the readme uses this method too.

Generally "follows" is synonymous with "depends upon." Unless there is a good reason, hyprland plugins should probably follow hyprland. It'll probably build either way, but it does become an issue with multiple plugins.

Great plugin by the way. My desktop space just tripled.

[wiillou]

I agree. The submodules are included by the url specified in inputs.hyprland.url. There is also a Nix way, but the github get request is more concise. I believe the readme uses this method too.

Generally "follows" is synonymous with "depends upon." Unless there is a good reason, hyprland plugins should probably follow hyprland. It'll probably build either way, but it does become an issue with multiple plugins.

Great plugin by the way. My desktop space just tripled.

the whole idea of following the hyprland version to the one in this plugin is such that the plugin will work on your computer since this plugin does not always follow master, which is likely around where your hyprland input in your flake is. You can do it that way but just might break more often if you update your flake and hyprland introduces a breaking change.

[adam-neeley]

Oh, I see. Well, that's why it's important for popular software projects like hyprland to minimize breaking changes.

Fortunately Nix was designed to provide granular control over versions of software, so the issue somewhat trivial. Still, users may want to other plugins and hyprland can only follow one.

[wiillou]

maybe we should add a note about that in the readme or something

[levnikmyskin]

A note about what exactly @wiillou? 🤔 About the hyprland version, we now also maintain a dev branch where compatibility with the latest git is usually more up to date.
This should already be in the readme though

[adam-neeley]

It would probably be sufficient to simply move the follows option to the plugin and it's attribute to hyprland. The code by @luiswirth is perfect for protecting against breaking changes and might form the basis of a good note.

[levnikmyskin]

Please feel free to open a PR :) @wiillou would you mind reviewing it in case?

[adam-neeley]

I'll absolutely take you up on that.
It's worth mentioning that the plugin is phenomenal, including the readme minus this minor technicality. Thank you for sharing it.

[adam-neeley]

I'm in the process of moving a long distance, but should have free time this upcoming Sunday to submit a PR.

I looked into the nix flake manual and would like to clarify a previous remark I made. The input url isn't actually a get request per se; just a string shorthand "url-like" that tells the flake what to do. It is in fact the nix way and how such things ought to be implemented in a situation like this.

[levnikmyskin]

No hurry, take your time

[adam-neeley]

I enjoy using nix, so it's a high priority. I also will verify that the PR uses canonical nix with more experienced nix enjoyers, so the published solution is peer-reviewed to fit standards and conventions. I'm currently just a hobbyist.

[adam-neeley]

I looked into things and am no longer sure that submitting a pull request is appropriate. The code that I would have put in the readme is verbatim the code contained in the flake.nix input. This isn't a matter of technical know-how, but a strategic decision that the author of the plugin should decide.

I'm glad I previously added the caveat unless there's a good reason, because there might be one. I'm not an expert, but I believe the only way to solve the problem would be for hyprland to distinguish between stable and unstable versions. The true cause of the issue seems to be the combination of hyprland frequently introducing breaking changes while supporting third party plugins. I think it's unfair for plugin developers.

Adding the code to the installation instructions would require users to micromanage the version of hyprland based on all the plugins they use. That is what I will be doing, but I don't think it's fair to expect everyone to do this. The current code might be as good as it gets given the situation.

I'd love to contribute to this plugin where I can, but I don't think this is it. Of course, I'm willing to be convinced otherwise, if there is new information or perspectives that I haven't considered.

[levnikmyskin]

I mean, Hyprland does have a (notreally) "stable" release and a (very) "unstable" one: that's the difference between the released versions and the -git main branches.
I decided to only officially support the Hyprland releases and not the main branch. Unfortunately, there's not much I can do if this clashes with other plugins' decision :( On the other hand, as I said, the dev branch of this plugin is usually kept pretty up to date

[adam-neeley]

Yeah, I agree it's a difficult situation and there seems to be not much anyone can do other than have hyprland follow this plugin, or users manually specify versions of both inputs.

I don't blame you at all. You are very generous to share this plugin and keep it regularly updated. You don't get paid and I know you have many other responsibilities.

Hopefully as time goes on, hyprland will mature and stabilize and this issue will mostly fade away.

I can add a note that says an alternative method is to manually specify the revision or tag of the inputs, and include a short snippet of code (but then the snippet would also have to be updated upon each update).

[levnikmyskin]

yeah, I also just noticed that the flake.nix tag is still on 0.40.0, I'll update this soon. In general, since I don't use nixos myself, I forget to update that file 😅

[adam-neeley]

Oh, I didn't notice either, maybe I was on dev.

I'm contemplating publishing my own distro of hyprland with every good plugin. I'll have to play around with it.

I can't really afford any risk of my system not building. Plus nix isn't known to provide the most helpful error messages, so minor compatability issues can be difficult to identify, especially since this occurs outside the purview of the nixpkgs repo.

Getting this plugin onto nixpkgs is another idea worth consideration. I will look into that as well.

[adam-neeley]

I stumbled upon a potential solution. Tag some revision for each version of hyprland. For example, users could do something like the following in their flake.nix:

  inputs = let hypr-version = "0.41.2";
  in {

    [...]

    hyprland.url =
      "git+https://github.com/hyprwm/Hyprland?submodules=1&ref=refs/tags/v${hypr-version}";

    hyprland-hy3.url = "github:outfoxxed/hy3?ref=hl${hypr-version}";
    hyprland-hy3.inputs.hyprland.follows = "hyprland";

    hyprland-plugins = {
      url = "github:hyprwm/hyprland-plugins?ref=refs/tags/hl${hypr-version}";
      inputs.hyprland.follows = "hyprland";
    };
};

Thanks to the hy3 plugin for the idea.

edit: Haha, I spoke too soon. Nix flakes don't allow typical nix expressions unless they are in the outputs attributes. My mistake.

Still, this would work, but users would have to manually type in the version for as many plugins as they use.

[luiswirth]

@adam-neeley yeah you are right! This is actually what I used for quite some time, but this requires that every plugin creates tags for their versions.
I believe fixing a specific revision/tag for hyprland and its plugins is currently the best solution.