Remove nix bits from repo and CI #5373
Conversation
These workflows fail often and I have no time or desire to learn nix to troubleshoot and resolve them. I have not been able to reach those that originally contributed them by mentions on commits on GH, and since I hate to have something that is essentially broken and opaque to me sitting in the repo, with no maintainers, I plan to remove it. See also my original position, and my later acceptance that was hoping that the community would be more active in looking after this: * #3547 (comment) * #3547 (comment) If this is to remain, I think I will need to have someone commit to looking after this stuff, and to commit to finding a replacement in the event that they no longer have the capacity to maintain it.
|
cc: @happenslol, @gabyx |
|
Hi @wez o/ May I ask where you mentioned people about Nix issues? 🤔 As for how to communicate and interact, tagging individuals may not be the most effective as you say, since not everyone has much time all the time... What do you think? Opened PR #5374 that should fix the build |
|
Fair enough. I'm in a place where I can't commit to maintaining this personally right now, so I won't push to keep this in the repo. I do think this would break a few setups though. |
|
I think there are a couple of logistical problems around the category of "stuff that wez cannot directly maintain in this repo":
More specifically for nix, I wonder if there is better automation possible. For #5374, is there a way to automatically update the nix stuff in that same way? Is that what https://github.com/wez/wezterm/blob/main/.github/workflows/update-flake.yml is intended to do? |
|
I don't know how realistic it is to automate package upgrades. Nix basically requires every input to the build to be locked to a specific revision, and upstream changes in the mainline nix package registry might change things around at any time, so imho manual maintenance is definitely required. I can understand that you don't want to have stuff in the repo that can be out of date some of the time, and of course you can't be expected to deal with nix things yourself just because of it's some of your users' preferred package manager. From my point of view, having nix in the repo provides the following benefits:
All of these can be achieved some way or another without having the files in the repo - it just removes a lot of friction and cuts down on fragmentation to have a "canonical" nix flake. From the start, I only opened the PR because I created the flake for myself and figured other people might want to use it too if the work is already done; not because I thought wezterm ought to support nix officially. I appreciate that you're still looking to make it work somehow, but for me personally it would be fine to merge this. The only reason I'm hesitant is because the original PR got some attention, so I'd assume that some people are using it. Their current setups will keep working, but whenever they attempt to update to the latest main revision after the merge, they'd have to switch back to either a custom flake or the packaged version from That's my personal opinion, and I don't wanna give of the impression that I have any authority on this - I'm just some nix user. The other people in the thread and the other PRs/issues might have other ideas. |
|
@happenslol : Fully agree with all what you said. I understand @wez for wanting the stuff deleted, however I find it extremely sad when Nix tooling is gone, I am currently fully using this Nix flake.nix file on my system and will continuing to do so. A tag on the PRs like |
|
I also currently use the Flake and love having it here, that said, I also follow all arguments listed above against having it here.
This workflow updates any of the Flake's
The last four are those dependencies that are usually included via a submodule. Unfortunately, they will not be touched by the workflow, which is designed to work for references to branches rather than specific commits or tags. For example, nixpkgs is included via the The workflow is currently failing because the Flake lives in the with:
pr-title: 'Update flake.lock' # Title of PR to be created
pr-labels: | # Labels to be set on the PR
dependencies
automated
pr-assignees: happenslol,gabyx,emiller88
+ path-to-flake-dir: 'nix/'should be the required fix. I took a look at the history of the As an immediate step to reduce the instances in which this happens, we could try to remove some of these inputs. nixpkgs includes versions of The other instances in which hash changes occured were in the context of Cargo dependencies on versions downloaded via Git. These are necessary every time you add or update a dependency on a Git repo. This can, unfortunately not be avoided but could also be automated with the right tooling. Unfortunately I'm not aware of any right now. |
|
If you are interested in transferring flake to org and managing it, I would be happy to help. By the way, it may be a good idea to enable |
These workflows fail often and I have no time or desire to learn nix to troubleshoot and resolve them.
I have not been able to reach those that originally contributed them by mentions on commits on GH, and since I hate to have something that is essentially broken and opaque to me sitting in the repo, with no maintainers, I plan to remove it.
See also my original position, and my later acceptance that was hoping that the community would be more active in looking after this:
If this is to remain, I think I will need to have someone commit to looking after this stuff, and to commit to finding a replacement in the event that they no longer have the capacity to maintain it.