Summary
We have a few development updates this week; our new logging tool will greatly improve debugging, and we’re getting some crates ready for the move from Rust nightly builds to Rust beta. We also have important information for DNA developers who have had some version conflicts and want to learn how to make all their development components work in harmony. There’s also a new feature to our Dev Pulse, the Summary by Dev Team shows what our teams are working toward in the current development cycle.
Highlights
1.How to Handle and Prevent Holochain Version Conflicts when Developing a DNA
2. New, Faster Logger with Filtering Capability for Core and lib3h
3. Bump Dependent Crate Versions in Preparation for Shift to Rust 1.38.0 Beta
4. Dev Team Progress Update
Details
1. How to Handle and Prevent Holochain Version Conflicts when Developing a DNA
We’ve gotten reports from several DNA developers who have experienced failing builds when updating to new Holochain versions. This is typically due to mismatches in the versions of the different components used in building DNAs — the Rust compiler for DNA development, the Rust compiler for the Conductor, the HDK, hc binaries, and Conductor. In this Dev Pulse, we’ll provide you some more context as to what these pieces do, how they work together, how to figure out when something’s wrong, and what you can do to fix it.
What About Holonix?
It may seem daunting to remember all these potential version conflicts, but remember that they only arise if you are directly downloading the binaries from the Holochain-Rust repository.
If you use Holonix, which we recommend, you’ll already have compiled binaries of all these components in the latest versions. Then, the only thing you would need to do is ensure that you update the target HDK version updated to the same version as the binaries in your existing Holonix environment.
You can find this in your zomes’ Cargo.toml files. If a new version of the HDK introduces any breaking changes, you’ll also need to update your source code.
Of course, Holonix itself isn’t free of version conflicts. We had an issue with the 0.0.23-alpha1 release; Holonix and its endpoint (https://holochain.love) progressed to a new Rust nightly version, but 0.0.23-alpha1 was still using the old version. As we mention below, we are working toward moving from nightly builds of Rust to Rust beta, which will eliminate these concerns. In the meantime, you can make sure that you are using the right version of Holonix by using the command hc — version to check the release tag of Holochain-Rust and the exact same nix-shell that we use for development.
https://holochain.love is great for hacking and messing around on the “latest” version, but for serious versioning, a project should always implement a default.nix file that can pin Holonix under the hood — just as the Holochain-Rust repository does.
Rust Compiler
The first two pieces you’ll need to keep in sync are:
- the Rust compiler for when you do DNA development, and
- the Rust compiler for when you compile the Conductor.
Each instance needs to be the same (or at least compatible) because we are using Rust nightly due to needed features that haven’t yet landed in Rust beta. Generally speaking, no two different Rust nightly versions are compatible. When the nightly builds for Rust are distributed, the Conductor and the HDK are updated, and both the DNA compiler and the Conductor compiler rely on the HDK. Therefore, every part needs to be aligned in order for them to work correctly.
Note: We are planning to switch from the nightly Rust builds to Rust beta for the next beta release (at least for the HDK), which should make things much easier.
HDK and the Conductor
The HDK that you reference as a dependency in your DNA’s Cargo.toml file needs to match the Conductor that runs your DNA after compiling. This makes sense, since the HDK acts as a Rust-based wrapper around a bunch of low-level functions that implement the API, connecting the Conductor to the DNA. If the HDK and the Conductor don’t match — for example, by updating the HDK to the newest version, but your Conductor is running the old version — you’re likely to get an error message.
Similarly, if you run an old DNA build in the new conductor, it won’t work anymore; you’ll need to update the HDK version in the Cargo.toml file and rebuild your DNA.
Here’s an example of the error you would see:
thread ‘main’ panicked at ‘Failed to instantiate module: Function(“host module doesn\’t export function with name hc_sign”)’, src/libcore/result.rs:997:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
It means that your DNA was compiled against an HDK version that assumed an API function (here hc_sign) to be there in the conductor run-time, but it’s not. This could be because we added it in a newer version, and though you’ve updated the HDK to that new version; you’re still trying to run it in an old conductor. Alternatively, it could mean that we removed or renamed the function, such that it is not there anymore, as in this case.
hc cli and the HDK
It’s important to remember that the hc command-line tools run some of your DNA’s code after compiling it. Our define_zome! macro in the HDK, or the procedural macros in the new proc-macro HDK, build meta-information from your declarations into a function that generates JSON to be included in the DNA. hc retrieves this information by instantiating the WASM module, loading your DNA, and calling that function. This saves you from having to hand write all the JSON that defines public functions, validators, and entry types. You do have to make sure that hc is the same version as the HDK; otherwise, you may get the same error messages you receive when you try to run a DNA with a mismatched Conductor.
2. New, Faster Logger with Filtering Capability for Core and lib3h (#1537) and (#1639)
Whether you’re a developer for Core, lib3h, or an app, you’ve likely had difficulty debugging due to not knowing what is happening “under the hood.” We initially came up with a logging solution in Core, but it didn’t cross crate boundaries, which limited how much you could actually see your code in operation. We’ve now revamped our logger to use idiomatic Rust conventions and allow for attaching logging to any context we choose — this means we’re able to bring in logging from lib3h, or any other crate, in which we’re interested.
We can also turn logging on or off as needed. Even better, the logger has configurable tagging and colors that let you filter information easily.
Aside from the obvious benefits to Core and lib3h developers, app developers will now better understand what’s going on within Holochain Core and see where networking signals are coming from and where they’re going.
The other big benefit to this change is that it standardizes how we are doing things across different crate developers.
3. Bump Dependent Crate Versions in Preparation for Shift to Rust 1.38.0 Beta (#1632)
Because the features on which we rely are not yet available in the beta version, we’ve been using the nightly builds of Rust in core development. However, the next beta release of Rust (1.38.0) is coming soon and we will soon be moving over to beta. A more stable version means that we won’t need to race to update Rust every night to make sure all of our components are compatible with one another. We’ll also be less likely to deal with code breaking, due to changes upstream. We may even be able to get rid of some of unneeded dependencies, which will make for a smoother experience for developers starting out on Holochain.
In preparation for the switch to Rust beta, we’ve changed the versions in the holochain_persistence (0.0.7), holochain_serialization (0.0.7) and lib3h (0.0.10) crates so that, when the switch comes, we’ll be ready.
4. Dev Team Progress Update
In our recent post on moving toward a Closed Alpha Testnet for Holo, we discussed how we intend to release in a series of waves, allowing us to gradually add new functionality while widening our testing community.
We are introducing a new feature in our Dev Pulse, shown below, which describes what each of our dev teams is working on at a high level, and how their work is progressing in relation to established milestones. In the future, it will align with our development sprint cycle.
Summary by Dev Team
Development Status:
- Released: 0.0.27-alpha1
- Next: 0.0.28-alpha1
For all changes related to this release, please see the changelog.
