You can and it’s pretty easy usually: Simply cherry-pick the changes with git.
The nixpkgs in my NIX_PATH (indirectly) points at GitHub - Atemu/nixpkgs: Nix Packages collection where I merge-pull nixos-unstable to update. When I need some change before it made it through the channel, I simply cherry-pick it.
You sound like you’d benefit from a setup like this too @uep.
This isn’t always optimal because it doesn’t account for caching but it’s the best you can do or reasonably expect. (What should and shouldn’t be built is a social problem.)
I cannot do this, because my configuration does not evaluate (because of some dependencies). I could now disable the affected derivations, or pin them to older versions but that is a lot of work. What I tend to do is wait until the problem is fixed in Nixpkgs.
Well, that’s what you get with rolling releases. They are inherently unstable like that. The only way to improve the situation is more maintainers and more thorough testing of the regular upstream.
Don’t know of one but it’s very simple conceptually (merge-pull unstable, cherry-pick off master) and the rest is just using git for which there are tutorials o’ plenty.
If there’s interest I could write up my strategy in a bit more detail.
EDIT: I replied before I saw that other people in the thread had also recommended this to you, sorry. But maybe there’ll still be something useful in what I wrote.
It seems to me that this exposes one of the (very few!) weaknesses of Nix. Namely, that you cannot (at least not in an easy way) pull in one change (let’s say a security change) without also pulling in all other changes that have been made (merged) in the meantime. On Arch/Debian/…, you can just postpone updating a major version of PHP, if you really wanted. Of course, then you also don’t have any guarantees that your package set plays together well.
Some people really don’t like this, but my reccomendation is to forgo channels, and have your own Nixpkgs git tree that you can pull in changes you want to. If all you’re doing is pulling in small changes that have already made it into master, then when you git pull --rebase to update to a new nixpkgs version, those changes will be transparently removed, so you’ll be back in sync and maintaining it won’t get out of hand.
I’d highly recommend using regular merge pulls. They let you easily trace back your steps without having to rely on the reflog and you can actually push them for synchronising Nixpkgs state between machines.
I’d highly recommend using regular merge pulls. They let you easily trace back your steps without having to rely on the reflog and you can actually push them for synchronising Nixpkgs state between machines.
That’s actually what I’d do as well, but I wouldn’t recommend them to a
beginner, because you’re basically committing to never using upstream
Nixpkgs again. With a rebase flow, on the other hand, unless you’re
doing something complicated, when you update you’ll end up on the same
git revision you’d get from using a channel.
The ideal solution is git-imerge, but the current
implementation is nowhere near fast enough to be useful for Nixpkgs.
When I tried it out it took more than a day to merge upstream Nixpkgs
into my tree.
What I like to do is to use rebase to keep the history clean and simple, but before I rebase, I create a new branch, so I can easily switch back to my previous branch.
What I like to do is to use rebase to keep the history clean and simple, but before I rebase, I create a new branch, so I can easily switch back to my previous branch.
Git automatically stores your version before rebasing in ORIG_HEAD, so there’s not even any need to manually create a new branch. (And if you’ve done more things since and ORIG_HEAD has been updated, you can look in git reflog.) But the reflog is automatically garbage collected eventually, so if there’s a chance you’ll want to go back a month from now to a previous version it still makes sense to create a branch.
Indeed. I create a new branch each time because it’s simple, explicit, and gives me a permanent history (I name my system branch (as opposed to a feature branches) current-1, then when I want to rebase it onto a new upstream commit, I’ll do git checkout -b current-2. It’s simple, it’s stupid and it works exceedingly well).
