🐇 Starting with completions is better. One question I have is whether the completions work for subcommands as usual, like in the static completions.

🐢 Yes, they work. We need to add:

source <(COMPLETE=zsh xvc)

to .zshrc, though.

🐇 It looks like we can drop the xvc completions command. We’re just checking the COMPLETE environment variable, and there’s no need for a separate command in this case.

🐢 Yes, let’s remove that.

🐇 Maybe we can employ a completions module for all completion-related functionality. It’s a separate thing, you know.

🐢 Which completions do we need?

🐇 We can just mark them with TODOs now.

🐢 Yes, let’s check where we need completions and what.

🐇 I noticed we’re repeating options in XvcFileCLI, and some of the options are missing, e.g., --from-ref and --to-branch.

🐢 Because it can compile into a different binary, and global options don’t work that way. Maybe we can move all these binaries into different files under lib. We can have feature flags to turn off certain features and compile different binaries.

🦊 Let’s search for it; I haven’t seen it before: building different binaries with feature flags using cargo.

🐢 There is no clear-cut solution, but it looks like we can move all binaries to the root with the required-features field.

🐲 We can postpone this to another release.

🐇 Yes, let’s not spend time on this now.

🐢 Should we try making pipeline_name a global option? It’s repeating everywhere.

🐇 That will make it easier to maintain.

🐢 We’ll have to pass pipeline_name to subcommands, though.

🐇 I think we can have a set of global options that we can pass. For the time being, that’s only the pipeline_name.

🐢 Okay. Let’s do this.

🐇 A similar option is the step name for pipeline steps.

🐢 Dependencies will need a revamp in the next version anyway. So let’s keep it for now.

🐲 Also, the semantics of step-name are different for these commands. step new interprets it as a new name, while step dependency interprets it as an existing name. The first can be renamed to --name, and the second can be --to, as one of its aliases suggests.

🐢 Yes, let’s keep it for now, and we’ll continue to work on others.

🦊 I want to post a comment in the clap discussions.

🐢 Wrote it. Now let’s build it after changing the pipeline_name.

🐇 It compiles. Should we test it?

🐢 I think we’ll test after all this completion work is done.

🐇 We did most of the strum-related completion.

🐢 Didn’t test them yet, though.

🐇 This is Rust. It will work if it compiles, and it compiles.

🐢 I think I can implement Rsync today. Looking at ssh2-rs, though, I think we can implement file transfer without relying on rsync. It might be easier to implement everything within the code.

🐇 Then you should rename the issue to new ssh.

🐢 Fair. There is also the ssh_rs crate, but it doesn’t have full support for the protocol. Instead, we can have another command, like xvc storage new ssh, that uses libssh2 via the crate mentioned above. It has some limitations with OpenSSH on macOS.

🐇 From the crate’s README, it looks like you can enable the vendored-openssl feature to compile it statically.

🐢 Let’s go ahead then. It’s better to compile it behind a feature flag, though.

🐇 Yup. Rsync can be separate. I think for now you can implement rsync via Exec::cmd and make new ssh a new issue.

🐢 I’ll copy this conversation there.

🐇 Now, let’s start implementing rsync.

🐢 Do we really want to hide it behind a feature flag? It doesn’t bring any extra complexity to generic, for example—just using the commands and returning the errors.

🐇 I think so. If the user doesn’t have rsync on their system, they’ll just get errors. We don’t need to make the implementation optional, but the tests might be.

🐢 OK.

The Cargo.toml file can have a [features] section. In this section, features can be defined, and they can enable other features.

[features]
my-feature = []
another-feature = ["my-feature"]

These markers are used in the code as follows:

#[cfg(feature = "my-feature")]
pub mod my_module;

The default features are listed under the default key of the [features] section. If it’s not defined, it’s considered empty, so cargo build supplies no features to the build system by default.

If you don’t want default features added automatically, you can use the --no-default-features option with cargo.

Starting from Rust 1.60, dependencies can be tied to features. When you define a dependency in the [dependencies] section, add optional = true to its options. Then, in [features], use the dep:package syntax.

[dependencies]

pack = { version = "1.0", optional = true }

[features]

my-feature = ["dep:pack"]

This way, Cargo doesn’t compile pack if my-feature is not enabled.

A caveat to using features is that they should be additive. There shouldn’t be a no-std feature to remove the standard library dependency; instead, you should define a std feature and enable it by default. The reason behind this is that Cargo ensures there is a single copy of a package with all the requested features enabled for the entire dependency graph. If you have a no-x feature that removes functionality, it breaks the additive logic of Cargo’s feature resolution.