{luaPackages,vimPlugins}: update on 2024-12-28#368843
{luaPackages,vimPlugins}: update on 2024-12-28#368843khaneliman merged 6 commits intoNixOS:masterfrom
Conversation
| }; | ||
|
|
||
| guard-nvim = super.guard-nvim.overrideAttrs { | ||
| nvimRequireCheck = "guard"; |
There was a problem hiding this comment.
Breaking release changes with no default module, letting auto discover find modules to test.
|
|
||
| nvim-notify = super.nvim-notify.overrideAttrs { | ||
| # Optional fzf integration | ||
| nvimSkipModule = "notify.integrations.fzf"; |
There was a problem hiding this comment.
They added fzf integration support recently
|
|
|
|
|
|
Sorry didn't notice the openscad failure before I left. What's the error? |
Unrelated: |
PerchunPak
left a comment
There was a problem hiding this comment.
LGTM, though @r-ryanth would run the update in ~two days
Would fail probably though |
|
Looking at the amount of rebuilds, it would probably open a PR to staging and skip nixpkgs-review |
We had this conversation a few times already.
We have been merging such updates to |
|
I agree with you. I'm not saying that we should target staging, I'm saying that @r-ryantm would target staging automatically. And we would probably end up rebasing it to master. |
Oh sorry I misread you then. Yes the bot would have targeted |
Note that it gets slower also by people merging such changes; you get there sooner at the expense of other PRs getting there slower. Our build farm is still mainly limited by rebuild count, not their complexity. (that can be surprising, I know, as it differs from what people experience locally) I see roughly one step per second in our metrics. This PR is 8k in total with additional 4k of "cached jobs", so I'd estimate that as 3–4h delay for the farm. Nothing terrible, but not negligible either. |
Yes, I heard that the rebuild count was important too. What do you suggest for the long term ? Having those bumps on |
|
Perhaps we could create a top 100 list by starts of our plugins, and update it in master. For everything else, we could do updates in staging. Or ditch the idea of packaging literally anything in nixpkgs, and have a requirement of > X stars. Everything else should go to a separate flake. |
|
You don't need to split it out of nixpkgs. But a possible thing to consider is that not everything would get built by Hydra. (or the majority would go through staging) |
|
One of my plans was to try and pin as many packages to releases as we can. Not everything needs to be latest git commit. Just need to update the plugin updater for vim plugins. |
You will regret touching that code, it is that bad... |
Building generated plugin is really simple and its cost to serve from hydra greatly outcomes cost of locally building. This also allows us to merge big rebuilds, where each rebuild is fairly simple, to master without delaying next branch update by a few hours (see NixOS#368843 (comment))
Things done
@GaetanLepage gonna see if its plugin related and test against this branch
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.