New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Overhaul nix flake update
and nix flake lock
UX
#8817
Overhaul nix flake update
and nix flake lock
UX
#8817
Conversation
nix flake update
and nix flake lock
UX
nix flake update
and nix flake lock
UXnix flake update
and nix flake lock
UX
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-09-01-nix-team-meeting-minutes-84/32466/1 |
944f6ab
to
315eb0d
Compare
Rebased on current master and fixed all tests. It's ready to merge, just needs a review. EDIT: Huh, seems the completion test passes on macOS and fails on Linux. Will investigate later. |
Alright, tests are fixed! This was a bit of a tough one, see the commit message for more info. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the nudge @iFreilicht. I actually had a WIP review but never finished it 馃槵
Apart from a few minor things, this is good to go from my side!
@edolstra you were assigned to this PR. Do you want to have another look? Otherwise I'll just merge it next week.
0719c38
to
872cd1b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Docs LGTM. The non-blocking nitpick applies to two instances. Update if you have time and agree it's an improvement.
872cd1b
to
40563f6
Compare
Adding the inputPath as a positional feature uncovered this bug. As positional argument forms were discarded from the `expectedArgs` list, their closures were not. When the `.completer` closure was then called, part of the surrounding object did not exist anymore. This didn't cause an issue before, but with the new call to `getEvalState()` in the "inputs" completer in nix/flake.cc, a segfault was triggered reproducibly on invalid memory access to the `this` pointer, which was always 0. The solution of splicing the argument forms into a new list to extend their lifetime is a bit of a hack, but I was unable to get the "nicer" iterator-based solution to work.
40563f6
to
f282ef5
Compare
Just rebased on top of Thanks a lot for that great change @iFreilicht ! |
@iFreilicht Thanks for your work getting this through! |
This is awesome! |
This probably should have kept around the previous @iFreilicht Would you be willing to tackle this? |
This builds on NixOS#8817, to add additional UX help for people with existing muscle memory (or shell history) with --update-input and tries to gently guide them towards the newly evolved CLI UI.
This builds on NixOS#8817, to add additional UX help for people with existing muscle memory (or shell history) with --update-input and tries to gently guide them towards the newly evolved CLI UI. Co-authored-by: Cole Helbling <cole.e.helbling@outlook.com>
This builds on #8817, to add additional UX help for people with existing muscle memory (or shell history) with --update-input and tries to gently guide them towards the newly evolved CLI UI. Co-authored-by: Cole Helbling <cole.e.helbling@outlook.com>
Hey this is a nice refresh for nix build --update-input nixpkgs So should we now do nix flake update nixpkgs && nix build instead? 馃憖 If this is the final decision, I can learn to live with it. |
@bryango Yes, that was the decision, and nobody objected at the time. Of course, this was not a data-driven decision, so I'd be curious to hear your use-case for |
Ah, there is not much that is "genuinely more useful" about Therefore, I would hope that the Update: oh, I just thought of something that could be "genuinely useful", but I am not sure if I have done it before, so this may or may not be realistic: suppose I want to try out some remote flake, but with some updated input; before I can do:
... without polluting the working directory at all, but now I will have to clone the remote flake first, |
In light of this, I think it would be better to un-deprecate the flags (while keeping the improved |
Got it, thank you for your thoughts! That imaginary workflow is indeed very useful, and would currently be served by What you show with The other reason is that nix has an issue with too few maintainers for too many features. While the flakes interface is still experimental, it makes sense to remove some features in favor of others to keep it as small as possible. Having multiple ways of achieving the same task makes keeping consistency, testing and documenting more difficult. Your demonstrated usecase is a potential feature for the future, but when it is implemented, we have to ensure it works properly in all situations it is available in. Right now, the priority regarding flakes is to stabilize them, so putting in the required amount of work to make this flag work as expected is not feasible, unless a contributor wants to take that over, and even then, finding time in a maintainers schedule can take months. So I would say deprecating and removing these flags is the best option right now. It says clearly: |
Motivation
The current interface of
nix flake lock
andnix flake update
is surprising and verbose. This lead to #5110, which has been open for over two years and is currently the fourth-most upvoted issue in this repository.After my proposal, some comments from users and a dedicated discussion from the Nix Team itself, this is the PR to fix this. The changes are as follows (copied directly from the release notes):
nix flake lock
only creates lock files and adds missing inputs now. It will never update existing inputs.nix flake update
does the same, but will update inputs.nix flake lock --update-input
--flake path/to/flake
.The flake-specific flags
--recreate-lock-file
and--update-input
have been removed from all commands operating on installables. They are superceded bynix flake update
.Testing
If you want to try out this PR, you can temporarily install it by running these two commands:
After that, running
nix flake lock
andnix flake update
will use the most current version of this PR.Context
See the links above for context.
My changes are pretty non-invasive. The only thing changed in the underlying
lockFlake
function are comments referring to the removed--update-input
flag and a tiny bugfix that causednix flake lock
to not actually output what it added to the lockfile when initially creating it. The code examples for bothnix flake lock
andnix flake update
were also incorrect, though those fixes are superseded by the new docs anyway.You'll also see a note in both docs that refers to a potential tripping hazard in the way
nix flake lock
andnix flake update
handle theflake-url
argument:To me this is clearly a bug, but I understand that the generality of flakes might make a seemingly obvious fix controversial, and I don't want this PR to be blocked because of that, so I'd be happy to create a separate PR for this issue.
Checklist for maintainers
Maintainers: tick if completed or explain if not relevant
tests/**.sh
src/*/tests
tests/nixos/*
Priorities
Add 馃憤 to pull requests you find important.