Add some tests for the CLI completion #6784

thufschmitt · 2022-07-11T13:28:05Z

Depends on #6693 (because it tests the new behavior it introduces)

ncfavier

We should maybe also add tests for tilde expansion (NIX_GET_COMPLETIONS=4 nix build ~/foo --override-input '') and completing inside a command line (NIX_GET_COMPLETIONS=4 nix build flake1 --update-input '' flake2)

ncfavier · 2022-07-11T13:41:08Z

tests/completions.sh

+popd
+
+# Test the completion of a subcommand
+[[ $(printf "normal\nbuild\t\n") == $(NIX_GET_COMPLETIONS=1 nix buil) ]]


Suggested change

[[ $(printf "normal\nbuild\t\n") == $(NIX_GET_COMPLETIONS=1 nix buil) ]]

[[ $(NIX_GET_COMPLETIONS=1 nix buil) == $'normal\nbuild\t\n' ]]

or

Suggested change

[[ $(printf "normal\nbuild\t\n") == $(NIX_GET_COMPLETIONS=1 nix buil) ]]

[[ $'normal\nbuild\t\n' == "$(NIX_GET_COMPLETIONS=1 nix buil)" ]]

== isn't symmetrical, in that the LHS is treated as a single word so you don't need to quote expansions, but the RHS is treated as a pattern so unquoted glob characters will mess things up. Also, no need for a command substitution to get a fixed string.

Oh yes, thanks. I've actually also inverted the order of things as it felt more natural to read (which I guess makes the quotes redundant, but it shouldn't really be a problem)

ncfavier · 2022-07-11T13:41:11Z

tests/completions.sh

+[[ $(printf "normal\na\t\n") == $(NIX_GET_COMPLETIONS=4 nix build ./foo --override-input '') ]]
+
+# Cli flag completion
+NIX_GET_COMPLETIONS=2 nix build --log-form | grep -- "--log-format"


grep -q maybe?

I like having the grep output for this kind of things since it's hidden by default but it gives a direct feedback as to whether the grep call found something or not when debugging (as it can be a bit tricky to understand which command exactly failed in the middle of a complex pipeline). Not that I have a very strong opinion about it though

Me neither.

dpulls · 2022-07-12T07:12:03Z

🎉 All dependencies have been resolved !

- Don't use `printf` for the expected result, but just use bash's `$' '` litteral strings - Quote the `nix` call result - Invert the order in the comparisons (just because it feels more natural)

Also add a disabled test for when the `--override-input` flag comes *before* the flake ref

thufschmitt · 2022-07-12T07:55:08Z

We should maybe also add tests for tilde expansion (NIX_GET_COMPLETIONS=4 nix build ~/foo --override-input '') and completing inside a command line (NIX_GET_COMPLETIONS=4 nix build flake1 --update-input '' flake2)

Yep' done that.
The completion inside a command-line seems broken though (I didn't expect this to happen that soon :p ). Apparently it's still picking the inputs from the flake at $PWD. I've left the test, but commented out and with a pointer to #6693

ncfavier · 2022-07-12T08:39:51Z

That's because you used --override-input, which expects two arguments, so it eats the next one which was supposed to be the flake. There's really no way to work around that (we might stop eating arguments as soon as one needs completion, but what if the user already specified a second argument and is now coming back to edit the first one? now we have an extra flake on the command line...), so the test should probably use --update-input as I showed

ncfavier · 2022-07-12T08:48:28Z

Two more test ideas:

nix flake show ./foo --override-input ''
multiple flakes: nix build ./foo ./bar --override-input ''

`--override-input` id snarky because it takes two arguments, so it doesn't play well when completed in the middle of the CLI (since the argument just after gets interpreted as its second argument). So use `--update-input` instead

- Test another command than `build` - Test with two input flakes

thufschmitt · 2022-07-13T08:33:26Z

That's because you used --override-input, which expects two arguments

Aaaah of course 🤦 Fixed it, it works all right now

Ericson2314 · 2023-02-08T01:25:22Z

This PR has confused me somewhat while I have been working on NixOS/rfcs#134. It appears we have gone from one two methods of doing completions? There is now both completionHook and completeFlakeInput which adds to the global completions variable.

It is not great having two methods of doing completions. We should have just one thing which can do everything we need.

ncfavier · 2023-02-08T09:16:43Z

By "this PR" I guess you mean #6693?

completeFlakeInput is a helper, just like completePath, for completing a flake input.

completionHook was needed for reasons I documented in that PR.

You're welcome to rewrite the whole thing if you find a better way.

Ericson2314 · 2023-02-08T14:00:17Z

Ah yes whoops I did mean the other PR.

Ericson2314 · 2023-02-08T14:03:48Z

You're welcome to rewrite the whole thing if you find a better way.

I might, but I am already in purgatory for making too many refactors.

In this case I fully believe yours is better --- the not-last-item completion is pretty killer --- but then we should strive to get rid of the old way.

Add some tests for the CLI completion

@thufschmitt

As I complained in NixOS#6784 (comment) (a comment on the wrong PR, sorry again!), NixOS#6693 introduced a second completions mechanism to fix a bug. Having two completion mechanisms isn't so nice. As @thufschmitt also pointed out, it was a bummer to go from `FlakeRef` to `std::string` when collecting flake refs. Now it is `FlakeRefs` again. The underlying issue that sought to work around was that completion of arguments not at the end can still benefit from the information from latter arguments. To fix this better, we rip out that change and simply defer all completion processing until after all the (regular, already-complete) arguments have been passed. In addition, I noticed the original completion logic used some global variables. I do not like global variables, because even if they save lines of code, they also obfuscate the architecture of the code. I got rid of them moved them to a new `RootArgs` class, which now has `parseCmdline` instead of `Args`. The idea is that we have many argument parsers from subcommands and what-not, but only one root args that owns the other per actual parsing invocation. The state that was global is now part of the root args instead. This did, admittedly, add a bunch of new code. And I do feel bad about that. So I went and added a lot of API docs to try to at least make the current state of things clear to the next person. -- This is needed for RFC 134 (tracking issue NixOS#7868). It was very hard to modularize `Installable` parsing when there were two completion arguments. I wouldn't go as far as to say it is *easy* now, but at least it is less hard (and the completions test finally passed).

@thufschmitt

As I complained in NixOS#6784 (comment) (a comment on the wrong PR, sorry again!), NixOS#6693 introduced a second completions mechanism to fix a bug. Having two completion mechanisms isn't so nice. As @thufschmitt also pointed out, it was a bummer to go from `FlakeRef` to `std::string` when collecting flake refs. Now it is `FlakeRefs` again. The underlying issue that sought to work around was that completion of arguments not at the end can still benefit from the information from latter arguments. To fix this better, we rip out that change and simply defer all completion processing until after all the (regular, already-complete) arguments have been passed. In addition, I noticed the original completion logic used some global variables. I do not like global variables, because even if they save lines of code, they also obfuscate the architecture of the code. I got rid of them moved them to a new `RootArgs` class, which now has `parseCmdline` instead of `Args`. The idea is that we have many argument parsers from subcommands and what-not, but only one root args that owns the other per actual parsing invocation. The state that was global is now part of the root args instead. This did, admittedly, add a bunch of new code. And I do feel bad about that. So I went and added a lot of API docs to try to at least make the current state of things clear to the next person. -- This is needed for RFC 134 (tracking issue NixOS#7868). It was very hard to modularize `Installable` parsing when there were two completion arguments. I wouldn't go as far as to say it is *easy* now, but at least it is less hard (and the completions test finally passed).

@thufschmitt

As I complained in NixOS#6784 (comment) (a comment on the wrong PR, sorry again!), NixOS#6693 introduced a second completions mechanism to fix a bug. Having two completion mechanisms isn't so nice. As @thufschmitt also pointed out, it was a bummer to go from `FlakeRef` to `std::string` when collecting flake refs. Now it is `FlakeRefs` again. The underlying issue that sought to work around was that completion of arguments not at the end can still benefit from the information from latter arguments. To fix this better, we rip out that change and simply defer all completion processing until after all the (regular, already-complete) arguments have been passed. In addition, I noticed the original completion logic used some global variables. I do not like global variables, because even if they save lines of code, they also obfuscate the architecture of the code. I got rid of them moved them to a new `RootArgs` class, which now has `parseCmdline` instead of `Args`. The idea is that we have many argument parsers from subcommands and what-not, but only one root args that owns the other per actual parsing invocation. The state that was global is now part of the root args instead. This did, admittedly, add a bunch of new code. And I do feel bad about that. So I went and added a lot of API docs to try to at least make the current state of things clear to the next person. -- This is needed for RFC 134 (tracking issue NixOS#7868). It was very hard to modularize `Installable` parsing when there were two completion arguments. I wouldn't go as far as to say it is *easy* now, but at least it is less hard (and the completions test finally passed).

@thufschmitt

As I complained in NixOS#6784 (comment) (a comment on the wrong PR, sorry again!), NixOS#6693 introduced a second completions mechanism to fix a bug. Having two completion mechanisms isn't so nice. As @thufschmitt also pointed out, it was a bummer to go from `FlakeRef` to `std::string` when collecting flake refs. Now it is `FlakeRefs` again. The underlying issue that sought to work around was that completion of arguments not at the end can still benefit from the information from latter arguments. To fix this better, we rip out that change and simply defer all completion processing until after all the (regular, already-complete) arguments have been passed. In addition, I noticed the original completion logic used some global variables. I do not like global variables, because even if they save lines of code, they also obfuscate the architecture of the code. I got rid of them moved them to a new `RootArgs` class, which now has `parseCmdline` instead of `Args`. The idea is that we have many argument parsers from subcommands and what-not, but only one root args that owns the other per actual parsing invocation. The state that was global is now part of the root args instead. This did, admittedly, add a bunch of new code. And I do feel bad about that. So I went and added a lot of API docs to try to at least make the current state of things clear to the next person. -- This is needed for RFC 134 (tracking issue NixOS#7868). It was very hard to modularize `Installable` parsing when there were two completion arguments. I wouldn't go as far as to say it is *easy* now, but at least it is less hard (and the completions test finally passed).

@thufschmitt

As I complained in NixOS#6784 (comment) (a comment on the wrong PR, sorry again!), NixOS#6693 introduced a second completions mechanism to fix a bug. Having two completion mechanisms isn't so nice. As @thufschmitt also pointed out, it was a bummer to go from `FlakeRef` to `std::string` when collecting flake refs. Now it is `FlakeRefs` again. The underlying issue that sought to work around was that completion of arguments not at the end can still benefit from the information from latter arguments. To fix this better, we rip out that change and simply defer all completion processing until after all the (regular, already-complete) arguments have been passed. In addition, I noticed the original completion logic used some global variables. I do not like global variables, because even if they save lines of code, they also obfuscate the architecture of the code. I got rid of them moved them to a new `RootArgs` class, which now has `parseCmdline` instead of `Args`. The idea is that we have many argument parsers from subcommands and what-not, but only one root args that owns the other per actual parsing invocation. The state that was global is now part of the root args instead. This did, admittedly, add a bunch of new code. And I do feel bad about that. So I went and added a lot of API docs to try to at least make the current state of things clear to the next person. -- This is needed for RFC 134 (tracking issue NixOS#7868). It was very hard to modularize `Installable` parsing when there were two completion arguments. I wouldn't go as far as to say it is *easy* now, but at least it is less hard (and the completions test finally passed).

@thufschmitt

As I complained in NixOS#6784 (comment) (a comment on the wrong PR, sorry again!), NixOS#6693 introduced a second completions mechanism to fix a bug. Having two completion mechanisms isn't so nice. As @thufschmitt also pointed out, it was a bummer to go from `FlakeRef` to `std::string` when collecting flake refs. Now it is `FlakeRefs` again. The underlying issue that sought to work around was that completion of arguments not at the end can still benefit from the information from latter arguments. To fix this better, we rip out that change and simply defer all completion processing until after all the (regular, already-complete) arguments have been passed. In addition, I noticed the original completion logic used some global variables. I do not like global variables, because even if they save lines of code, they also obfuscate the architecture of the code. I got rid of them moved them to a new `RootArgs` class, which now has `parseCmdline` instead of `Args`. The idea is that we have many argument parsers from subcommands and what-not, but only one root args that owns the other per actual parsing invocation. The state that was global is now part of the root args instead. This did, admittedly, add a bunch of new code. And I do feel bad about that. So I went and added a lot of API docs to try to at least make the current state of things clear to the next person. -- This is needed for RFC 134 (tracking issue NixOS#7868). It was very hard to modularize `Installable` parsing when there were two completion arguments. I wouldn't go as far as to say it is *easy* now, but at least it is less hard (and the completions test finally passed).

@thufschmitt

As I complained in NixOS#6784 (comment) (a comment on the wrong PR, sorry again!), NixOS#6693 introduced a second completions mechanism to fix a bug. Having two completion mechanisms isn't so nice. As @thufschmitt also pointed out, it was a bummer to go from `FlakeRef` to `std::string` when collecting flake refs. Now it is `FlakeRefs` again. The underlying issue that sought to work around was that completion of arguments not at the end can still benefit from the information from latter arguments. To fix this better, we rip out that change and simply defer all completion processing until after all the (regular, already-complete) arguments have been passed. In addition, I noticed the original completion logic used some global variables. I do not like global variables, because even if they save lines of code, they also obfuscate the architecture of the code. I got rid of them moved them to a new `RootArgs` class, which now has `parseCmdline` instead of `Args`. The idea is that we have many argument parsers from subcommands and what-not, but only one root args that owns the other per actual parsing invocation. The state that was global is now part of the root args instead. This did, admittedly, add a bunch of new code. And I do feel bad about that. So I went and added a lot of API docs to try to at least make the current state of things clear to the next person. -- This is needed for RFC 134 (tracking issue NixOS#7868). It was very hard to modularize `Installable` parsing when there were two completion arguments. I wouldn't go as far as to say it is *easy* now, but at least it is less hard (and the completions test finally passed).

@thufschmitt

As I complained in NixOS#6784 (comment) (a comment on the wrong PR, sorry again!), NixOS#6693 introduced a second completions mechanism to fix a bug. Having two completion mechanisms isn't so nice. As @thufschmitt also pointed out, it was a bummer to go from `FlakeRef` to `std::string` when collecting flake refs. Now it is `FlakeRefs` again. The underlying issue that sought to work around was that completion of arguments not at the end can still benefit from the information from latter arguments. To fix this better, we rip out that change and simply defer all completion processing until after all the (regular, already-complete) arguments have been passed. In addition, I noticed the original completion logic used some global variables. I do not like global variables, because even if they save lines of code, they also obfuscate the architecture of the code. I got rid of them moved them to a new `RootArgs` class, which now has `parseCmdline` instead of `Args`. The idea is that we have many argument parsers from subcommands and what-not, but only one root args that owns the other per actual parsing invocation. The state that was global is now part of the root args instead. This did, admittedly, add a bunch of new code. And I do feel bad about that. So I went and added a lot of API docs to try to at least make the current state of things clear to the next person. -- This is needed for RFC 134 (tracking issue NixOS#7868). It was very hard to modularize `Installable` parsing when there were two completion arguments. I wouldn't go as far as to say it is *easy* now, but at least it is less hard (and the completions test finally passed).

@thufschmitt

As I complained in NixOS#6784 (comment) (a comment on the wrong PR, sorry again!), NixOS#6693 introduced a second completions mechanism to fix a bug. Having two completion mechanisms isn't so nice. As @thufschmitt also pointed out, it was a bummer to go from `FlakeRef` to `std::string` when collecting flake refs. Now it is `FlakeRefs` again. The underlying issue that sought to work around was that completion of arguments not at the end can still benefit from the information from latter arguments. To fix this better, we rip out that change and simply defer all completion processing until after all the (regular, already-complete) arguments have been passed. In addition, I noticed the original completion logic used some global variables. I do not like global variables, because even if they save lines of code, they also obfuscate the architecture of the code. I got rid of them moved them to a new `RootArgs` class, which now has `parseCmdline` instead of `Args`. The idea is that we have many argument parsers from subcommands and what-not, but only one root args that owns the other per actual parsing invocation. The state that was global is now part of the root args instead. This did, admittedly, add a bunch of new code. And I do feel bad about that. So I went and added a lot of API docs to try to at least make the current state of things clear to the next person. -- This is needed for RFC 134 (tracking issue NixOS#7868). It was very hard to modularize `Installable` parsing when there were two completion arguments. I wouldn't go as far as to say it is *easy* now, but at least it is less hard (and the completions test finally passed). Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>

@thufschmitt

As I complained in NixOS#6784 (comment) (a comment on the wrong PR, sorry again!), NixOS#6693 introduced a second completions mechanism to fix a bug. Having two completion mechanisms isn't so nice. As @thufschmitt also pointed out, it was a bummer to go from `FlakeRef` to `std::string` when collecting flake refs. Now it is `FlakeRefs` again. The underlying issue that sought to work around was that completion of arguments not at the end can still benefit from the information from latter arguments. To fix this better, we rip out that change and simply defer all completion processing until after all the (regular, already-complete) arguments have been passed. In addition, I noticed the original completion logic used some global variables. I do not like global variables, because even if they save lines of code, they also obfuscate the architecture of the code. I got rid of them moved them to a new `RootArgs` class, which now has `parseCmdline` instead of `Args`. The idea is that we have many argument parsers from subcommands and what-not, but only one root args that owns the other per actual parsing invocation. The state that was global is now part of the root args instead. This did, admittedly, add a bunch of new code. And I do feel bad about that. So I went and added a lot of API docs to try to at least make the current state of things clear to the next person. -- This is needed for RFC 134 (tracking issue NixOS#7868). It was very hard to modularize `Installable` parsing when there were two completion arguments. I wouldn't go as far as to say it is *easy* now, but at least it is less hard (and the completions test finally passed). Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>

@thufschmitt

As I complained in NixOS#6784 (comment) (a comment on the wrong PR, sorry again!), NixOS#6693 introduced a second completions mechanism to fix a bug. Having two completion mechanisms isn't so nice. As @thufschmitt also pointed out, it was a bummer to go from `FlakeRef` to `std::string` when collecting flake refs. Now it is `FlakeRefs` again. The underlying issue that sought to work around was that completion of arguments not at the end can still benefit from the information from latter arguments. To fix this better, we rip out that change and simply defer all completion processing until after all the (regular, already-complete) arguments have been passed. In addition, I noticed the original completion logic used some global variables. I do not like global variables, because even if they save lines of code, they also obfuscate the architecture of the code. I got rid of them moved them to a new `RootArgs` class, which now has `parseCmdline` instead of `Args`. The idea is that we have many argument parsers from subcommands and what-not, but only one root args that owns the other per actual parsing invocation. The state that was global is now part of the root args instead. This did, admittedly, add a bunch of new code. And I do feel bad about that. So I went and added a lot of API docs to try to at least make the current state of things clear to the next person. -- This is needed for RFC 134 (tracking issue NixOS#7868). It was very hard to modularize `Installable` parsing when there were two completion arguments. I wouldn't go as far as to say it is *easy* now, but at least it is less hard (and the completions test finally passed). Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>

@thufschmitt

As I complained in #6784 (comment) (a comment on the wrong PR, sorry again!), #6693 introduced a second completions mechanism to fix a bug. Having two completion mechanisms isn't so nice. As @thufschmitt also pointed out, it was a bummer to go from `FlakeRef` to `std::string` when collecting flake refs. Now it is `FlakeRefs` again. The underlying issue that sought to work around was that completion of arguments not at the end can still benefit from the information from latter arguments. To fix this better, we rip out that change and simply defer all completion processing until after all the (regular, already-complete) arguments have been passed. In addition, I noticed the original completion logic used some global variables. I do not like global variables, because even if they save lines of code, they also obfuscate the architecture of the code. I got rid of them moved them to a new `RootArgs` class, which now has `parseCmdline` instead of `Args`. The idea is that we have many argument parsers from subcommands and what-not, but only one root args that owns the other per actual parsing invocation. The state that was global is now part of the root args instead. This did, admittedly, add a bunch of new code. And I do feel bad about that. So I went and added a lot of API docs to try to at least make the current state of things clear to the next person. -- This is needed for RFC 134 (tracking issue #7868). It was very hard to modularize `Installable` parsing when there were two completion arguments. I wouldn't go as far as to say it is *easy* now, but at least it is less hard (and the completions test finally passed). Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>

@thufschmitt

As I complained in NixOS/nix#6784 (comment) (a comment on the wrong PR, sorry again!), #6693 introduced a second completions mechanism to fix a bug. Having two completion mechanisms isn't so nice. As @thufschmitt also pointed out, it was a bummer to go from `FlakeRef` to `std::string` when collecting flake refs. Now it is `FlakeRefs` again. The underlying issue that sought to work around was that completion of arguments not at the end can still benefit from the information from latter arguments. To fix this better, we rip out that change and simply defer all completion processing until after all the (regular, already-complete) arguments have been passed. In addition, I noticed the original completion logic used some global variables. I do not like global variables, because even if they save lines of code, they also obfuscate the architecture of the code. I got rid of them moved them to a new `RootArgs` class, which now has `parseCmdline` instead of `Args`. The idea is that we have many argument parsers from subcommands and what-not, but only one root args that owns the other per actual parsing invocation. The state that was global is now part of the root args instead. This did, admittedly, add a bunch of new code. And I do feel bad about that. So I went and added a lot of API docs to try to at least make the current state of things clear to the next person. -- This is needed for RFC 134 (tracking issue #7868). It was very hard to modularize `Installable` parsing when there were two completion arguments. I wouldn't go as far as to say it is *easy* now, but at least it is less hard (and the completions test finally passed). Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io> Change-Id: If18cd5be78da4a70635e3fdcac6326dbfeea71a5 (cherry picked from commit 67eb37c1d0de28160cd25376e51d1ec1b1c8305b)

@thufschmitt

As I complained in NixOS/nix#6784 (comment) (a comment on the wrong PR, sorry again!), #6693 introduced a second completions mechanism to fix a bug. Having two completion mechanisms isn't so nice. As @thufschmitt also pointed out, it was a bummer to go from `FlakeRef` to `std::string` when collecting flake refs. Now it is `FlakeRefs` again. The underlying issue that sought to work around was that completion of arguments not at the end can still benefit from the information from latter arguments. To fix this better, we rip out that change and simply defer all completion processing until after all the (regular, already-complete) arguments have been passed. In addition, I noticed the original completion logic used some global variables. I do not like global variables, because even if they save lines of code, they also obfuscate the architecture of the code. I got rid of them moved them to a new `RootArgs` class, which now has `parseCmdline` instead of `Args`. The idea is that we have many argument parsers from subcommands and what-not, but only one root args that owns the other per actual parsing invocation. The state that was global is now part of the root args instead. This did, admittedly, add a bunch of new code. And I do feel bad about that. So I went and added a lot of API docs to try to at least make the current state of things clear to the next person. -- This is needed for RFC 134 (tracking issue #7868). It was very hard to modularize `Installable` parsing when there were two completion arguments. I wouldn't go as far as to say it is *easy* now, but at least it is less hard (and the completions test finally passed). Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io> Change-Id: If18cd5be78da4a70635e3fdcac6326dbfeea71a5 (cherry picked from commit 67eb37c1d0de28160cd25376e51d1ec1b1c8305b)

ncfavier reviewed Jul 11, 2022

View reviewed changes

thufschmitt added 4 commits July 12, 2022 09:24

Add some tests for the CLI completion

32effcc

Fix the name of the completions test

260fb83

Harden the comparisons in the completion test

07e14d3

- Don't use `printf` for the expected result, but just use bash's `$' '` litteral strings - Quote the `nix` call result - Invert the order in the comparisons (just because it feels more natural)

Test the tilde expansion for the flake completion

21c443d

Also add a disabled test for when the `--override-input` flag comes *before* the flake ref

thufschmitt force-pushed the completion-test branch from c89fca8 to 21c443d Compare July 12, 2022 07:52

thufschmitt added 2 commits July 13, 2022 10:25

Fix the “out of order” completion test

d34a333

`--override-input` id snarky because it takes two arguments, so it doesn't play well when completed in the middle of the CLI (since the argument just after gets interpreted as its second argument). So use `--update-input` instead

Add some more completion tests

b052e7e

- Test another command than `build` - Test with two input flakes

ncfavier approved these changes Jul 13, 2022

View reviewed changes

thufschmitt merged commit fbd0a6c into NixOS:master Jul 18, 2022

Minion3665 pushed a commit to Minion3665/nix that referenced this pull request Feb 23, 2023

Merge pull request NixOS#6784 from tweag/completion-test

964d840

Add some tests for the CLI completion

Ericson2314 mentioned this pull request Mar 29, 2023

Overhaul completions, redo #6693 #8131

Merged

7 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add some tests for the CLI completion #6784

Add some tests for the CLI completion #6784

thufschmitt commented Jul 11, 2022

ncfavier left a comment

ncfavier Jul 11, 2022 •

edited

Loading

thufschmitt Jul 12, 2022

ncfavier Jul 11, 2022

thufschmitt Jul 12, 2022

ncfavier Jul 12, 2022

dpulls bot commented Jul 12, 2022

thufschmitt commented Jul 12, 2022

ncfavier commented Jul 12, 2022 •

edited

Loading

ncfavier commented Jul 12, 2022

thufschmitt commented Jul 13, 2022

Ericson2314 commented Feb 8, 2023

ncfavier commented Feb 8, 2023

Ericson2314 commented Feb 8, 2023

Ericson2314 commented Feb 8, 2023 •

edited

Loading

	[[ $(printf "normal\nbuild\t\n") == $(NIX_GET_COMPLETIONS=1 nix buil) ]]
	[[ $(NIX_GET_COMPLETIONS=1 nix buil) == $'normal\nbuild\t\n' ]]

	[[ $(printf "normal\nbuild\t\n") == $(NIX_GET_COMPLETIONS=1 nix buil) ]]
	[[ $'normal\nbuild\t\n' == "$(NIX_GET_COMPLETIONS=1 nix buil)" ]]

Add some tests for the CLI completion #6784

Add some tests for the CLI completion #6784

Conversation

thufschmitt commented Jul 11, 2022

ncfavier left a comment

Choose a reason for hiding this comment

ncfavier Jul 11, 2022 • edited Loading

Choose a reason for hiding this comment

thufschmitt Jul 12, 2022

Choose a reason for hiding this comment

ncfavier Jul 11, 2022

Choose a reason for hiding this comment

thufschmitt Jul 12, 2022

Choose a reason for hiding this comment

ncfavier Jul 12, 2022

Choose a reason for hiding this comment

dpulls bot commented Jul 12, 2022

thufschmitt commented Jul 12, 2022

ncfavier commented Jul 12, 2022 • edited Loading

ncfavier commented Jul 12, 2022

thufschmitt commented Jul 13, 2022

Ericson2314 commented Feb 8, 2023

ncfavier commented Feb 8, 2023

Ericson2314 commented Feb 8, 2023

Ericson2314 commented Feb 8, 2023 • edited Loading

ncfavier Jul 11, 2022 •

edited

Loading

ncfavier commented Jul 12, 2022 •

edited

Loading

Ericson2314 commented Feb 8, 2023 •

edited

Loading