🐇 What about adding at least command completions for Nushell?

🐢 Let’s read a bit about clap_complete_nushell.

🦊 There seems to be a nu-complete command. Let’s check its documentation.

🐇 Nothing was found, and Kagi doesn’t help much either.

🐢 There is a completions document for Nushell: https://www.nushell.sh/book/custom_completions.html

🐇 There is a tool called carapace to provide completions across shells.

🐢 Its documentation is thin, and I’m not sure if it supports dynamic completions out of the box. I believe instead of adding a carapace setup, we can just write a Nushell completion script that will use JSON output from the commands and add some (maybe hidden) utility commands to support it.

🐇 There are a set of example scripts in the Nushell repo: https://github.com/nushell/nu_scripts/tree/main/custom-completions

🐢 The reason I want to write custom completions for Nushell is that it will be an exercise for the scripting language. gh completions are not as scary as a Bash script.

🐇 git completions are a better example for XVC. They simply run git whenever necessary. We can start from a static completions command and update this with dynamic completions manually. It will teach a lot.

🐢 I forked the nu_scripts repo and will add XVC completions script there.

🐇 Then let’s begin by adding Nushell static completions. Shall we add a command for this?

🦊 Reviving the completion command we removed in 0.6.13?

🐢 We shouldn’t list it. We can make a _comp subcommand for the time being and generate and distribute completions in the repository. When clap_complete_nushell has the feature parity to provide dynamic completions, we can remove these commands.

🐇 What will we use this for other than generating completions?

🐢 Maybe dynamic completions can call this as well.

🐇 Added Nushell static completions to be output using xvc _comp generate-nushell. Let’s bump up the version to 0.6.15.

cargo set-version 0.6.15-alpha.1
   Upgrading xvc from 0.6.14 to 0.6.15-alpha.1
...

🐢 I noticed we forgot a line in the CLI command handler that asserts xvc_root_opt.is_some(), and this fails when we run xvc outside of repositories. We need to release this version quickly.

🐇 Oops, now, ok, let’s write a static Nushell generator and just release quickly.

🦊 Generating completions with

xvc comp generate-nushell

🐢 Completion command is run with comp instead of _comp. Should we rename it?

🐇 Renamed it to _comp. It’s not hidden, but at least we can be sure that it won’t be misunderstood as a common command.

🐢 Bumping the version again. Now let’s source the generated script and test it.

cargo set-version 0.6.15-alpha.2
   Upgrading xvc from 0.6.15-alpha.1 to 0.6.15-alpha.2
...

🦊 Yep, it works. We now have completions for Nushell.

🐢 Let’s update the completions documentation.

🐇 Done. Now, let’s take a look at CI and see what fails.

ghrl | first
╭──────────────┬─────────────────────────────────────────────────────────╮
│ conclusion   │ success                                                 │
│ displayTitle │ Add Nushell completions                                 │
│ headBranch   │ nushell-completions                                     │
│ url          │ https://github.com/iesahin/xvc/actions/runs/13070200765 │
╰──────────────┴─────────────────────────────────────────────────────────╯

🐢 It fails because of coverage, not the tests. Codecov says the new code isn’t tested.

🐇 The added xvc _comp command isn’t tested. We can add a test running those lines and testing if the command outputs a completion script.

🐢 We have a test for completions. We can add a test that runs the lines.

🐇 Added a test and bumping up the version.

cargo set-version 0.6.15-alpha.3
   Upgrading xvc from 0.6.15-alpha.2 to 0.6.15-alpha.3
...

🦊 We can add some more coverage while waiting for the tests.

🐇 XvcOutputLine implementation seems to have no tests. It’s weird because we use these everywhere.

🐢 I’m not sure we use this particular implementation; we just use XvcOutputLine::Info(s), not XvcOutputLine::info(s) anywhere. We can delete these methods actually.

🐇 We’ll add JSON output via this particular struct. Can we refactor these to use formatting for JSON, for example? Or use these to output JSON?

🦊 We can add a formatter to XvcOutputLine to output structures.

🐢 The enum is now defined as:

#[derive(Clone, Debug)]
pub enum XvcOutputLine {
    /// The output that we should be reporting to user
    Output(String),
    /// For informational messages
    Info(String),
    /// For debug output to show the internals of Xvc
    Debug(String),
    /// Warnings that are against some usual workflows
    Warn(String),
    /// Errors that interrupts a workflow but may be recoverable
    Error(String),
    /// Panics that interrupts the workflow and ends the program
    /// Note that this doesn't call panic! automatically
    Panic(String),
    /// Progress bar ticks.
    /// Self::Info is also used for Tick(1)
    Tick(usize),
}

Here, these fields can also have a formatter that will render the string in a particular format. For example, the output can be

XvcOutputLine::Output(XvcJsonFormatter, String)

🐇 I’m not sure this is a good idea. Output already specifies this string as output. We can have a wrapper instead, like,

struct XvcJsonOutput(Format<XvcStructuredOutput>, XvcStructuredOutput)

and we can use the supplied format to render XvcStructuredOutput to an output line with XvcOutputLine::Output. If we don’t provide output as structured, it will be too much error-prone work to convert the current outputs to structured.

🦊 The transition will also be gradual. We may not need structured output for most of the commands. We can start with xvc file list and convert others as we go.

🐢 This is sensible. By the way, coverage still didn’t increase. There may be something going on with Codecov or running the test.

ghrl | first
╭──────────────┬─────────────────────────────────────────────────────────╮
│ conclusion   │ success                                                 │
│ displayTitle │ Add Nushell completions                                 │
│ headBranch   │ nushell-completions                                     │
│ url          │ https://github.com/iesahin/xvc/actions/runs/13087431038 │
╰──────────────┴─────────────────────────────────────────────────────────╯

🐇 Let’s run the test:

cargo test -p xvc --test test_completions
...
test test_completions ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.80s

🐢 Can we make sure the output is a Nushell script and not an error message?

🐇 Let’s print it out.

🐢 It looks like when the COMPLETE environment variable is set, it never calls _comp subcommand and never calls those lines.

cargo set-version 0.6.15-alpha.4
   Upgrading xvc from 0.6.15-alpha.3 to 0.6.15-alpha.4
...

🐢 Let’s make a release for 0.6.15. Coverage is OK now.

cargo set-version 0.6.15
   Upgrading xvc from 0.6.15-alpha.4 to 0.6.15
...

gh pr merge --squash --body $"(open CHANGELOG.md | lines | skip 2 | take 5)" --subject "Add static nushell completions"

🐇 Merged the PR.

🐢 Releases should appear in a few minutes.

🐇 We need to tag the merge commit for this.

🐢 Oh, yep. AFAIK Lazygit doesn’t have something for git push --tags. Let’s push from the CLI.

git push --tags
You are on the main branch. Skipping CHANGELOG.md check.
To github.com:iesahin/xvc
 * [new tag]         v0.6.15 -> v0.6.15

🦊 These commands, especially tables, are not rendered correctly on the web. We need to change the theme, I think.

🐇 We can just complete the completions for this version and add JSON output for all commands to use in nushell. In the meantime, dynamic completions support for nushell is likely to be added.

🐢 Umm, yep. Then we’ll continue to run tests with zsh for the current version.

🐇 run-tests is a zsh file, and we will continue to use it. We can switch to nushell eventually as we add more compatibility with it, but let’s not do this now.

🐢 Where were we the last time for completions?

🐇 We added xvc_path_completers. Let’s check the TODO list now.

🐢 We still need tracked_targets completions in a few places.

🐇 Added those.

🐢 Now we have some strum completers. Let’s finish these up as well.

🐇 Ok. They are done as well.

🐢 Now, let’s start adding a storage_identifier completer. It should read all XvcStorage records and list their names.

🐇 Added a storage_identifier completer. Let’s add it to all places where we use storage_identifiers.

🐢 Now, we need completers for pipeline and step names. These are straightforward.

🐇 Added these. Let’s fill up where they are needed.

🐢 I want to skip some of the fine-grained completions in this version. We can have a specific completer for --params options for files and params inside, for example. Or a special completer for directories.

🐇 Let’s not forget these. Reading YAML files and extracting hyperparameter keys for the prompt would be a really good feature for the user.

🐢 I agree. These are good features in general, but we need to ship the current version as soon as possible.

🐇 Let’s check the TODO comments once more.

$ rg 'TODO:' 
...
- ✅ pipeline/src/pipeline/api/update.rs:    /// TODO: Add a repository_dirs completer (11:08)
- ✅ file/src/remove/mod.rs:    /// TODO: Add a storage_identifier completer (11:08)
- ✅ file/src/bring/mod.rs:    /// TODO: Add a storage_identifier completer (11:08)
...

🦊 We can use xvc_path_completer for the tracked directory completer for the time being. For pipeline update, we can use a ValueHint instead. It’s not necessary to use a custom completion.

🐢 For the xvc file copy destination, we can have a file or a directory that we track and is not available, or we don’t track and is available. It’s a similar situation to xvc_path_completer, but we also need to check the local paths. It requires some more care.

🐇 Now we can begin to run the tests.

🐢 Is this building?

🐇 It should.

🐢 We also have one bug. xvc shouldn’t print help text when the COMPLETE environment variable is set.

🐇 Umm, yeah, that’s a blocker.

🐢 Fixed it. We can bump the version and push the changes.

🐲 We can work on completions or the GUI.

🐢 Completions are similar to the Homebrew work. It’s in another ecosystem and feels boring.

🐲 We can try to make it in Rust: “Writing shell completions in Rust.”

🐢 There are two solutions: One is clap_complete (https://docs.rs/clap_complete/latest/clap_complete/) and the other is shell_completion (https://github.com/JoshMcguigan/shell_completion). The latter is very new but may be what we need: writing completions only with Rust.

🐲 The shell_completion crate is very bare-bones. It doesn’t have anything, actually. https://github.com/JoshMcguigan/shell_completion/issues/1

🐇 The feature that we need is dynamic completion. We’ll write something similar to ArgValueCompleter for this.

🦊 I think we can just start a new branch.

🐲 We have a branch for Homebrew; should we merge it?

🐢 I think, yes, we can merge it. We’ll fix it if it breaks. It’s a separate workflow file anyway.

🦊 Created the PR.

ghpl
264	add brew tap	add-brew-tap	OPEN	2025-01-03T05:14:45Z

🐢 Merged it.

🐇 Now let’s create a new branch and add clap-complete to Cargo.toml.

🐲 There are some packages that we need to take a look at. thiserror now has v2.

🐢 Upgraded packages and compiled. It works.

🐲 Let’s update the version.

🐢 Done. Now we can add clap-complete.

🦊 Added with the unstable-dynamic command. Can we build it again?

🐢 Built it. Now we can add a completions subcommand to Xvc.

🐲 Is this the right name for this?

🐢 It will output a shell script that we can source in the shell.

🐲 Okay, let’s add the subcommand now.

🐢 The example doesn’t work with the clap builder.

🐇 Let’s search for it.

🐢 I think we’re extending ourselves a bit when trying to add all dynamic features of completion at once. We can just start by adding completion to xvc-test-helper.

🐇 Yep, that’s a better idea. We can have many more examples, and it’s certainly more straightforward.

🐢 One thing I noticed when working yesterday is that using auto-save was actually preventing many of these swap errors.

🐲 It was a bit slow. Can we take a look at a few others?

🐢 https://github.com/okuuva/auto-save.nvim seems a bit more polished.

🐇 Installed it, but haven’t seen an effect yet.

🐢 We may need to restart this.

🐲 Now, we can get into the test-helper completions.

🐢 Done. Added these quickly as you thought. Now adding this to main seems much easier.

🦊 That was a nice approach. Let’s dive into adding this to main.

🐇 Should we go with a separate command or just an option?

🐲 Our commands have distinct initial letters, allowing them to be used with just those letters. Adding another top-level command for this will make c useless.

🐢 I don’t think that’s a valid concern. We can create aliases for all commands and completions shouldn’t have to have an alias. But I agree that completions should not be a top-level command. It will be run once for installation at most.

🦊 I agree. Let’s call it --completions. It will be run as xvc --completions zsh and will print out the completions.

🐢 Okay. Let’s do this.

🦊 No errors left. Let’s install this version.

🐢 We get:

error: 'xvc' requires a subcommand but one was not provided
  [subcommands: file, init, pipeline, storage, root, check-ignore, aliases, help]

Usage: xvc [OPTIONS] <COMMAND>

For more information, try '--help'.

🦊 Umm, okay. I think we don’t have an option to create a command like that. Then we’ll have to print completions with a subcommand.

🐲 The above discussion is now moot. ❌

🐢 We can try to push, but probably it’s not worth it.

🐲 Let’s not lose time on this. I think we can remove the aliases command and replace it with completions, and add single-letter aliases to subcommands.

🐢 We can have an option in the completions command to print aliases. That will work.

🦊 I don’t think people will use the aliases command if we have single-letter command aliases.

🐢 You may be right. No need to try to maintain that at this time.

🐢 Good morning, and I’m fed up with these blink.cmp errors, you know.

🐇 Reinstalling blink works. It’s interesting to rely on such unreliable software.

🐢 Oh, yeah. It’s interesting. Where were we yesterday?

🐲 We decided to rename the aliases command to completions.

🐇 And waiting for rust-analyzer to complete its analysis.

🐢 Uh, yeah. I see.

🦊 The code itself is very short, actually.

    if let Some(shell) = cli_opts.completions {
        let mut cmd = XvcCLI::command();
        generate(shell, &mut cmd, "xvc", &mut io::stdout());
        return Ok(None);
    }

🐲 We’ll use the output! macro instead of writing to io::stdout(), right?

🐢 Yes, we can rely on the usual output system. It will be slower to create an output thread but shouldn’t matter for outputting a shell script.

🐇 It takes a while for rust-analyzer to scan all the directories, it looks like. When I close the project, it just cannot reload it immediately.

🐢 We can use cargo clean from time to time.

🦊 rust-analyzer finished scanning; let’s try to rename AliasesCLI.

🐲 Let’s keep these here; maybe we’ll need them in our scripts:

# Standard Xvc command aliases for longer commands.
alias xls='xvc file list'
alias pvc='xvc pipeline'
alias fvc='xvc file'
alias xvcf='xvc file'
alias xvcft='xvc file track'
alias xvcfl='xvc file list'
alias xvcfs='xvc file send'
alias xvcfb='xvc file bring'
alias xvcfh='xvc file hash'
alias xvcfco='xvc file checkout'
alias xvcfr='xvc file recheck'
alias xvcp='xvc pipeline'
alias xvcpr='xvc pipeline run'
alias xvcps='xvc pipeline step'
alias xvcpsn='xvc pipeline step new'
alias xvcpsd='xvc pipeline step dependency'
alias xvcpso='xvc pipeline step output'
alias xvcpi='xvc pipeline import'
alias xvcpe='xvc pipeline export'
alias xvcpl='xvc pipeline list'
alias xvcpn='xvc pipeline new'
alias xvcpu='xvc pipeline update'
alias xvcpd='xvc pipeline dag'
alias xvcs='xvc storage'
alias xvcsn='xvc storage new'
alias xvcsl='xvc storage list'
alias xvcsr='xvc storage remove'

🦊 We can use them when adding single-letter aliases.

🐇 There is a from_env method for Shell; will we support it?

🦊 I think we can support it. It’s much easier to use if we omit the shell.

🐲 We had aliases in xvc-core, but we need to access XvcCLI from completions. The completions module must be moved to xvc.

🦊 We added the clap_complete dependency to the xvc-pipeline and xvc-file crates, but I don’t think they are necessary. Let’s remove them now.

🐢 Now only the test-helper and xvc crates have the clap_complete dependency.

🐇 Are we ready to test?

🐢 Completions are working. 🎉

🐲 Now we need to update the docs and doc tests, I believe.

🐢 There are also tests to update.

🐇 Tests are running now. In the meantime, can we take a look at the blink configuration?

🐲 When we removed xvc aliases, we also removed pvc, xls, and other aliases. Maybe we can add these to the docs.

🐢 We can put them in the xvc completions reference for now.

🐢 It takes a while for rust-analyzer to finish analyzing the codebase.

🦊 Added aliases for xvc pipeline commands. Do you think we need to repeat root-level flags in xvc-pipeline?

🐢 No need to divert attention, I believe. Also, I still think there is an easier way to do that.

🐇 Okay. Do you think we should add easier subcommands to step? Like, step new becoming xvc p s n instead of xvc p s n? (Wait, that’s the same). I mean, more concise.

🐢 I think we can extend these even to the top-level, but shouldn’t make them visible. It will pollute the help text. We can add xvc fl for file list to avoid the space, but hide these from the help text.

🐲 That’s a good idea, but it will require including sub-crate level modules at the top level. We must test it first.

🐢 Let’s finish up the current changes and release them first.

🐇 By the way, we didn’t add two-letter abbreviations to the xvc storage new subcommands. Do you think we need them?

🐢 When we think about the frequency of these commands, no, I don’t think we need them. Users won’t add a new storage every day.

🐇 By that logic, we shouldn’t need an n for xvc storage new.

🐢 Actually, yeah. Maybe we should remove even s.

🦊 storage list may be useful.

🐢 s is a very common letter, though. We can have other uses for that letter.

🐇 Updating xvc p s dependency options, but it looks like making dependency options subcommands is a better way.

🦊 We didn’t do it because currently we can supply multiple options with a single command. If we go the subcommand route, we’ll have to write all dependencies one by one. Adding multiple subcommands with clap is a bit tricky.

🐢 Umm. Yeah, I see.

🐇 Maybe we can provide a separate command to add multiple dependencies. Like, xvc p s d add 'lines=myfile.csv::10-20; file=myimage.jpg; glob=dir/image-10*'

🐲 That looks like the start of a language. We need a parser for those strings. They will be freeform.

🦊 Another option is to keep the current options and add commands with the same names.

🐢 That will be confusing. The user will have both --param and param, and they will work differently.

🐇 We can have an add command that accepts the current options. Parsing will be done by clap just like now, but for a subcommand of dependency.

🐢 The full command will be something like xvc pipeline step --step-name preprocessing dependency add --params 'params.json::batch_size'

🐇 With shorter commands, it’s like xvc p s -s preprocessing d a --params 'params.json::batch_size', and this doesn’t look like ffmpeg monstrosities.

🐲 In any case, this is a backward-incompatible change. This should wait for v0.7 along with ECS changes.

🐢 ECS changes are not user-visible, but these are. Certainly needs a minor version update.

🐇 Then, okay, let’s keep the current ones for this version and think about updating them in a future version.

🐢 Okay. Let’s finish up and we’ll create a separate invisible subcommand to ask questions to the Xvc repo for completions.

🐇 We completed completions for the common command structure. Now, we need a way to show certain info after certain commands. A tab after xvc p r -p should show pipeline names, for example.

🐢 Umm, yeah. And these should be as quick as possible. They shouldn’t check Git or any other things.

🐇 I looked here and there, and the only working example I found is here: https://github.com/clap-rs/clap/blob/master/clap_complete/tests/testsuite/zsh.rs#L248 in clap_complete tests.

🐢 Let’s try to dive in. We can start by cloning the repo, I believe.