Swayfx #2
Swayfx #2
Conversation
| @@ -18,6 +19,8 @@ | |||
| systemdSupport | |||
| trayEnabled | |||
| ; | |||
|
|
|||
| wlroots_0_17 = wlroots_0_16; | |||
There was a problem hiding this comment.
😢 maybe we should make it wlroots there after all then
There was a problem hiding this comment.
Is there a guideline that prefers that? I don't see anything in contributing.md or pkgs/readme.md on that.
And to me, it's further obscuring the dependencies...
There was a problem hiding this comment.
Neither is great, but passing wlroots_0_16 for wlroots_0_17 seems rather confusing to me...
There was a problem hiding this comment.
I think this ends up being the limitation of the current pkgs/by-name approach.
But really, I think we should just decouple swayfx from sway derivation instead. Copy-and-paste sometimes is better than having coupling between packages, and the fact that any change in sway can break swayfx is a strong argument to not having those 2 derivations share code.
| # This patch was backported into SwayFX | ||
| # remove when next release is rebased on Sway 1.9 | ||
| patches = | ||
| let | ||
| removePatches = [ | ||
| "LIBINPUT_CONFIG_ACCEL_PROFILE_CUSTOM.patch" | ||
| ]; | ||
| in | ||
| builtins.filter | ||
| (patch: !builtins.elem (patch.name or null) removePatches) | ||
| (oldAttrs.patches or [ ]); |
There was a problem hiding this comment.
I think this is another good example on why trying to reuse code sometimes ends up unnecessary complicating things.
I am in favor of just making those 2 derivations completely independent. WDYT @raboof @eclairevoyant ?
There was a problem hiding this comment.
It's a balance between avoiding duplication and being autonomous.
For my own Sway fork, Volare, the build 'itself' is independent (https://codeberg.org/raboof/volare/src/branch/main/flake.nix#L10) but I do re-use the sway module (https://codeberg.org/raboof/volare#when-using-flakes-for-your-nixos-configuration).
There was a problem hiding this comment.
I think this approach is just causing an additional maintenance burden. Decoupling would solve all problems and avoid new ones in the future.
Also, if I remember correctly overriding packages causes a few strange issues, for example the update scripts don't work as it should (they try to update the original package instead the overriden one).
There was a problem hiding this comment.
Also, if I remember correctly overriding packages causes a few strange issues, for example the update scripts don't work as it should
I would call this a bug in the update script. But yes, let's eventually decouple these. They are fundamentally just different codebases, have different release schedules, etc. and have diverged substantially by now.
Fixes swayfx breakages when bumping sway version