| Crates.io | etcd-bin-vendored |
| lib.rs | etcd-bin-vendored |
| version | 3.5.26 |
| created_at | 2024-09-22 00:03:56.158139+00 |
| updated_at | 2026-01-16 21:10:31.058957+00 |
| description | etcd precompiled binaries bundled into a crate |
| homepage | https://github.com/tgockel/rust-etcd-bin-vendored |
| repository | https://github.com/tgockel/rust-etcd-bin-vendored |
| max_upload_size | |
| id | 1382585 |
| size | 17,734 |
etcd Bundled in a CrateThis crate provides access to an etcd binary for the purpose of unit testing.
The core of this library is the etcd_bin_path function, which gets a path to an etcd binary which is compatible with
this operating system and architecture.
etcd_bin_vendored::etcd_bin_path().unwrap();
This is meant to be used as the program for an [std::process::Command].
To quickly spin up an etcd server for testing purposes, do something like this:
let etcd_path = etcd_bin_vendored::etcd_bin_path()
.expect("etcd-bin-vendored should provide a valid path");
let client_port = 2379u16; // <- randomize it
let mut command = std::process::Command::new(etcd_path);
command
.arg("--listen-client-urls")
.arg(format!("http://127.0.0.1:{client_port}"))
.arg("--advertise-client-urls")
.arg(format!("http://127.0.0.1:{client_port}"));
let mut process = command.spawn().expect("failed to launch etcd");
// Do things with a client library
println!("etcd running -- listening at 'http://127.0.0.1:{client_port}'");
// Error handling which makes sense to you, probably in a `Drop` impl
process.kill().expect("failed to kill etcd");
process.wait().expect("waiting for etcd to stop was not successful");
Note that the code above will cause etcd to use the current working directory as the data directory, so you will see a
directory named default.etcd appear wherever you ran this from.
To prevent this, you can use tempdir and the --data-dir argument so you don't end up testing with stale
data.
It is also good practice to pick a random unused client_port so you can run tests in parallel.
There is a good argument for moving these to a generic helper library.
To minimize library size, the actual binaries are packaged inside of platform-specific libraries.
For example, the etcd-bin-vendored-linux-amd64 crate contains the binary for running
on Linux AMD64.
By default, the platform-specific crate is enabled for the detected target.
In other words, the etcd-bin-vendored-darwin-arm64 package is a required dependency
when you are running on MacOS with ARM64 silicon.
You can also select supported platforms manually.
For example, if you know your system is only ever ARM64 Linux, you can use the platform-specific etcd_bin_path
directly.
Take care with this, as the binary is always available, but it might not be runnable on your architecture.
target_os |
target_arch |
feature |
Crate |
|---|---|---|---|
linux |
x86_64 |
linux-x86_64 |
etcd-bin-vendored-linux-amd64 |
linux |
aarch64 |
linux-aarch64 |
etcd-bin-vendored-linux-arm64 |
linux |
powerpc64 |
linux-powerpc64 |
etcd-bin-vendored-linux-ppc64le |
linux |
s390x |
linux-s390x |
etcd-bin-vendored-linux-s390x |
macos |
x86_64 |
macos-x86_64 |
etcd-bin-vendored-darwin-amd64 |
macos |
aarch64 |
macos-aarch64 |
etcd-bin-vendored-darwin-arm64 |
windows |
x86_64 |
windows-x86_64 |
etcd-bin-vendored-windows-amd64 |
Note: Naming
There is a bit of incongruity between the platform-specific feature names and their respective crate names; e.g.: the
macos-aarch64feature maps to theetcd-bin-vendored-darwin-arm64crate. The reason for this is the features map to the Rust conventions fortarget_osandtarget_arch, while the crates map toGOOSandGOARCHplatform conventions, whichetcduses directly. My thinking is that someone using the meta-crate will be more familiar with Rust conventions, while someone looking to pull a specific binary will be more familiar with Go conventions.
The versions of this library match the etcd version.
So, pulling this library at version 3.5.23 means you get the binaries for etcd release 3.5.23.
This crate is not useful for distributing etcd to your application.
It merely pulls the etcd binary from its own Cargo manifest.
If you try to use this function outside of a Cargo test on the system it was built on, it will not work.
The advantage of this is that it makes it impossible to use this in production.
That is an advantage because you should not be running a critical service like etcd from a binary you pulled from some
random crate.
This is for unit/integration testing only.
This crate gives you a binary blob ultimately downloaded from etcd releases on GitHub.
Before running anything changing library versions, you should verify that the binary downloaded by this library matches
what you find on the release.
Note that this library gives the executable inside the archive (etcd/etcd.exe), not the whole archive, so the SHA
sums listed on GitHub will not match; you have to download the archive, unpack it, and do this yourself.
If an etcd release gets yanked for security reasons, I will also yank it from Crates.
If I have not done this, open an issue with a "security" tag.