`Couldn't traverse DNA in directory` with `nix-shell https://holochain.love`

How to reproduce:

  • rust 1.38-nightly (2019-08-08) + target wasm32-unknown-unknown
  • nix-shell


  • enter nix-shell https://holochain.love
  • create a new repo and cd into it with hc init some-app; cd some-app
  • create a zome with hc generate zomes/zome1 rust-proc
  • run hc package

The whole build log is:

> CARGO_TARGET_DIR=${CARGO_TARGET_DIR:-/tmp/my_first_app/target} && echo $CARGO_TARGET_DIR 
Error: Couldn't traverse DNA in directory "/Users/me/src/github.com/user/somedir/some-app": No such file or directory (os error 2)

Am I doing something wrong ? If not, is there something I can try as a workaround ?

@nmrshll it looks like you’re on a Mac, and I know we’ve been having some build issues on Macs. hc --version shows 0.0.38-alpha14, right? Have you updated to macOS Cordova? (If you haven’t, don’t do it yet! The Nix package manager is having some real struggles with Cordova.)

Thanks for the answer. Yes, I work on a mac at the moment, and I haven’t updated (precisely to avoid dealing with new problems). So that’s one more reason I won’t update soon.
Yes, my hc version (inside the holonix shell) is hc 0.0.38-alpha14. I also have a version of it installed outside, which is on 0.0.40-alpha1.

Is there a way to “pin”/specify the https://holochain.love version I want to use ? I could try with an older version, I definitely had it working sometimes with older versions.
Else I’m going to try with different combinations of rust/hc versions.

Okay, this is definitely not a Mac issue; I can reproduce it in Linux too by following your steps, but can’t reproduce it on an existing project. I saw some chatter about this problem in our internal chat; will look into it.

Thanks a lot.

I do have an older project (that was already set up) where the same last command works.
Maybe the holonix data has been cached in the other repo so it keeps working, and some change on holochain.love makes it not work the first time anymore ?

FWIU the holonix stuff is tied to the user rather than the folder, although I could be wrong. I suspect there’s a bug in the freshly generated templates…

Hey @nmrshll and @pauldaoust
I’m also getting the same issue also on Linux.

I can successfully run hc package after hc init though. It is only after I generate a new zome then run hc package that I get the error (same as above).

Also I’m only getting the error when I create a new Happ. Previously created Happs seem to package ok.

I had the same issue yesterday, fixed by using https://github.com/holochain/holonix/archive/v0.0.60.tar.gz instead of https://holochain.love

Turns out it’s an issue in .38 that’s going away in the next ‘blessed’ holochain.love release. It’s some hardcoded build commands in the zome’s .hcbuild file that doesn’t actually work. In the meantime you can open up zomes/<zome_name>/code/.hcbuild and edit thusly:

    "steps": [
-     {
-       "command": "CARGO_TARGET_DIR=${CARGO_TARGET_DIR:-/tmp/my_first_app/target} && echo $CARGO_TARGET_DIR",
-       "arguments": []
-     },
-       "command": "CARGO_TARGET_DIR=${CARGO_TARGET_DIR:-/tmp/my_first_app/target} && cargo",
+       "command": "cargo",
        "arguments": [
-         "--target-dir=$CARGO_TARGET_DIR"
-       "command": "CARGO_TARGET_DIR=${CARGO_TARGET_DIR:-/tmp/my_first_app/target} && wasm-gc",
-       "arguments": ["$CARGO_TARGET_DIR/wasm32-unknown-unknown/release/zome1.wasm"]
+       "command": "wasm-gc",
+       "arguments": ["target/wasm32-unknown-unknown/release/zome1.wasm"]
-       "command": "CARGO_TARGET_DIR=${CARGO_TARGET_DIR:-/tmp/my_first_app/target} && wasm-opt",
+       "command": "wasm-opt",
        "arguments": [
-         "$CARGO_TARGET_DIR/wasm32-unknown-unknown/release/zome1.wasm"
+         "target/wasm32-unknown-unknown/release/zome1.wasm"
-       "command": "CARGO_TARGET_DIR=${CARGO_TARGET_DIR:-/tmp/my_first_app/target} && wasm2wat",
+       "command": "wasm2wat",
        "arguments": [
-         "$CARGO_TARGET_DIR/wasm32-unknown-unknown/release/zome1.wasm",
+         "target/wasm32-unknown-unknown/release/zome1.wasm",
-         "$CARGO_TARGET_DIR/wasm32-unknown-unknown/release/zome1.wat"
+         "target/wasm32-unknown-unknown/release/zome1.wat"
-       "command": "CARGO_TARGET_DIR=${CARGO_TARGET_DIR:-/tmp/my_first_app/target} && wat2wasm",
+       "command": "wat2wasm",
        "arguments": [
-         "$CARGO_TARGET_DIR/wasm32-unknown-unknown/release/zome1.wat",
+         "target/wasm32-unknown-unknown/release/zome1.wat",
-         "$CARGO_TARGET_DIR/wasm32-unknown-unknown/release/zome1.wasm"
+         "target/wasm32-unknown-unknown/release/zome1.wasm"
-   "artifact": "${CARGO_TARGET_DIR:-/tmp/my_first_app/target}/wasm32-unknown-unknown/release/zome1.wasm"
+   "artifact": "target/wasm32-unknown-unknown/release/zome1.wasm"

(Alternately, you could copy a known working .hcbuild into zomes/zome1/code and replace all instances of the zome name with zome1.)

… Then just make sure you only ever run hc build from the root dir of your DNA project.

Oh this is a good point. Even using the latest version any zomes created with the old template will need to be updated.
You can find the new template here.
This will only work with the new release which will be on holochain.love very shortly. Or you can access it now like this:

nix-shell https://github.com/holochain/holonix/archive/develop.tar.gz

You will also have to update the {{ name }} with the name of your some.

Thanks for all the troubleshooting and the quick fix !

And thanks to @Glunk for showing me how to pin holochain.love versions.
With this and the new fix published, this is what worked for me:

nix-shell https://github.com/holochain/holonix/archive/v0.0.61.tar.gz

and then hc init, generate, and package.
Good thing is, this will likely keep working forever.

I’m seeing the same problem - supposedly holochain.love is updated now (according to https://github.com/holochain/docs-pages/issues/169 but I’m seeing this problem in the Hello-World Tutorial

I’ve just found it’s also possible to reproduce this error if you name a zome using kebab-case. For example:

hc generate zomes/kebab-case rust-proc
hc package

snake_case seems to work fine. Is that the preferred convention?

@Joss this is really interesting – it’s a totally separate issue with almost the same symptoms! It fails at a different stage in the build process though – whereas the above bug was all about checking for the existence of the final build artifact, this one fails earlier. It seems to be related to the way cargo works – it forces snake_case in build artifacts.

I’ve filed a bug for this: https://github.com/holochain/holochain-rust/issues/2177

It seems to be related to some sort of snake_case enforcement in cargo or rustc itself. Apparently there’s not yet any way to specify a filename for the build artifact when running cargo (although rustc does let you do that). So it looks like it’ll require some string magic on our end.

Thanks! Seems simplest that I get used to using snake_case.