Giter Site home page Giter Site logo

holochain-cmd's Introduction

Holochain Command Line Tools

Repo Contents Moved!

NOTE: This repo has now been merged into holochain-rust

Project PM Chat

This repo provides a set of tools for building and running Holochain DNA from the command line. The tools are written in Rust, and delivered as binary executables.

Install

Our recommended pattern for the installation of hc command line tools is to use the Developer Preview release that you can find here, along with its instructions: https://github.com/holochain/app-spec-rust/releases/tag/v0.0.1-dev-preview. Otherwise, you can proceed with the more complex instructions for building from source, below.

Building From Source

These dependencies need to be installed in order to compile, and use holochain-cmd:

  • Rust
    • needs to be the nightly build, so use the following commands, once you have first installed Rust
    • rustup toolchain install nightly
    • rustup default nightly
    • Also, if you are going to be developing Zomes in Rust, install the WASM build target for Rust, by running:
    • rustup target add wasm32-unknown-unknown --toolchain nightly
  • Node.js (needed for running tests)
  • hcshell (also needed for running tests, hcshell is currently installed as part of holosqape)

To install the Holochain command line, run the following commands in a terminal

$ git clone https://github.com/holochain/holochain-cmd.git
$ cd holochain-cmd
$ git submodule init
$ git submodule update
$ cargo install -f --path .

The command line tools are now available in your command line using the hc command. Run hc -V to confirm. Run hc help for help.

Usage

(u) means the command is not yet implemented.

Command Use
init Initializes a new Holochain app at the given directory
generate Generates a new Zome
package Builds the current Holochain app into a .dna.json file
unpack Unpacks a Holochain bundle into its original file system structure
test Runs tests written in the test folder
web (u) Starts a web server for the current Holochain app
agent (u) Starts a Holochain node as an agent

How To Get Started Building An App

In your terminal, change directories to one where you wish to initialize a new Holochain app. Run the following, replacing your_app_name with your actual app name:

$ hc init your_app_name
$ cd your_app_name

We now have the empty shell of a Holochain app. From here, we will want to generate at least one Zome. To do this, run the following, replacing your_zome_name with a name related to the functionality you wish to develop. For example: users.

$ hc generate zomes/your_zome_name

Currently, only Zomes written in Rust can be generated. In the future, you may be able to generate Zomes in another language. hc generate scaffolds the files and config you need to get started.

What this did is generate a new folder under zomes called users. Here is the folder structure of it.

  • users
    • code
      • src
        • lib.rs
      • .build
      • Cargo.toml

So in every Zome there must be a code folder, which can be compiled into a single WASM binary with the code for this Zome.

Now that you have your Rust Zome, check out the two sources of documentation about writing Holochain DNA source code:

  1. https://holochain.github.io/holochain-rust
  2. https://holochain.github.io/rust-api/0.0.1/hdk

In order for Holochain to run your app, you have to build your code into a single packaged file. Those instructions follow.

What are .dna.json files?

Holochain DNA can be fully contained in a file known as a .dna.json file. It is a JSON file, with a particular structure that Holochain can understand, and execute.

This is an unusual JSON file; it is part configuration, and part executable.

The configuration part comes from the json file at the top level of your source code.

The executable part comes from having embedded Base64 encoded WebAssembly code in the file. What does that mean? WebAssembly is a fast and secure low-level language. Rather than storing the code in its ugly raw WASM bytecode format, Holochain expects the code to be encoded using Base64 , for legibility and simplicity reasons.

If you haven't heard of WebAssembly (WASM for short), that's ok. Important to know is that WASM is intended as a "compilation target" for other languages, not a language to write code in. So instead of writing code in WASM, write code in a language that's familiar to you, and supports WASM. When it's time to run your code in Holochain, compile it.

In order to avoid having to handcraft this complex JSON structure, with lots of room for error, the hc package command streamlines the process of taking your "raw" application folder, and packaging it up into the final .dna.json file.

More information about this follows.

Using Built-in Compilation

The hc package tool will automate the process of compiling your Zome code, encoding it, and inserting into the .dna.json file. In order to get these benefits, you just need to make sure that you have the right compilation tools installed on the machine you are using the command line tools from, and that you have the proper configuration files in your Zome folders.

hc package works with two special files called .hcignore files and .build files.

.build files

In the process of building a .dna.json file, here is what Holochain does.

  • It iterates Zome by Zome adding them to the JSON
  • For each Zome, it looks for any folders containing a .build file
  • For any folder with a .build file, it executes one or more commands from the .build file to create a WASM file
  • It takes that built WASM file and Base64 encodes it, then stores a key/value pair for the Zome with the key as the folder name and the encoded WASM as the value

When using hc generate to scaffold a Zome, you will have a .build file automatically. If you create your Zome manually however, you will need to create the file yourself. Here's the structure of a .build file, using a Rust Zome which builds using Cargo as an example:

{
  "steps": {
    "cargo": [
      "build",
      "--release",
      "--target=wasm32-unknown-unknown"
    ]
  },
  "artifact": "target/wasm32-unknown-unknown/release/code.wasm"
}

The two top level properties are steps and artifact. steps is a list of commands which will be sequentially executed to build a WASM file. artifact is the expected path to the built WASM file. Under steps, each key refers to the bin of the command that will be executed, such as cargo. The value of cargo, the command, is an array of arguments: build, and the two -- flags. In order to determine what should go here, just try running the commands yourself from a terminal, while in the directory of the Zome code.

Ignoring using .hcignore files

Sometimes, you'll want to exclude files and folders in your project directory to get a straight .dna.json file that can be understood by Holochain. In order to do that, just create a .hcignore file. It has a similar structure to .gitignore files:

README.md
dist
.DS_Store

The package command includes patterns inside .gitignore files automatically, so you don't have to write everything twice. Also hidden files are ignored by default as well.

Rust -> WASM compilation tools

If we take Zome code in Rust as an example, you will need Rust and Cargo set up appropriately to build WASM from Rust code. WASM compilation is available on the nightly Rust toolchain. To enable it, run the following:

$ rustup toolchain install nightly
$ rustup target add wasm32-unknown-unknown --toolchain nightly # adds WASM as a compilation target
$ rustup default nightly # switch to the nightly rust toolchain as your default

Once that's done, you should be able to run commands like cargo build --target=wasm32-unknown-unknown and have it work.

Once all of this is set up, you can build and run your .dna.json file with Holochain!

Writing and Running Tests

By default, when you use hc init to create a new project folder, it creates a sub-directory called test. The files in that folder are equipped for testing your project.

Checkout the README of our default testing configuration to understand how to write your tests in Javascript: https://github.com/holochain/js-tests-scaffold.

Once you have a project folder initiated, you can run hc test to execute your tests. This combines the following steps:

  1. Packaging your files into a DNA file, located at dist/bundle.json. This step will fail if your packaging step fails.
  2. Installing build and testing dependencies, if they're not installed (npm install)
  3. Building a single JS file used for testing, placed at test/dist/bundle.js (npm run build)
  4. Executing (with hcshell) the test file found at test/dist/bundle.js

hc test also has some configurable options.

If you want to run it without repackaging the DNA, run it with

hc test --no-package

If you want to run it without running the npm commands, run it with

hc test --skip-npm

If your tests are in a different folder than test, run it with

hc test --dir tests

where tests is the name of the folder.

If the file you wish to actually execute is somewhere besides test/dist/bundle.js then run it with

hc test --testfile test/test.js

where test/test.js is the path of the file.

You have the flexibility to write tests in quite a variety of ways, open to you to explore.

Note about default configuration with TAPE testing: If you use the default configuration with Tape for testing, to get an improved CLI visual output (with colors! and accurate script exit codes), we recommend adjusting the command you use to run tests as follows:

hc test | test/node_modules/faucet/bin/cmd.js

Contribute

Holochain is an open source project. We welcome all sorts of participation and are actively working on increasing surface area to accept it. Please see our contributing guidelines for our general practices and protocols on participating in the community.

License

License: GPL v3

Copyright (C) 2018, Holochain Trust

This program is free software: you can redistribute it and/or modify it under the terms of the license p rovided in the LICENSE file (GPLv3). This program is distributed in the hope that it will be useful, bu t WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Note: We are considering other 'looser' licensing options (like MIT license) but at this stage are using GPL while we're getting the matter sorted out. See this article for some of our thinking on licensing for distributed application frameworks.

holochain-cmd's People

Contributors

connoropolous avatar ddd-mtl avatar lucksus avatar maackle avatar philipbeadle avatar sphinxc0re avatar thedavidmeister avatar zippy avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

holochain-cmd's Issues

Windows can not run hc test. Plus first time using github!

After successfully compile the code. Bug discovered while trying to run hc test on Windows. It returns Error: The system cannot find the file specified. (os error 2)

image

When trying to run hc package. It suppose to have a complete dna by filling in the zome. But nothing added.
image

Can anybody test on their Windows as well to see if they have the same issue?

Add top-level Cargo.toml workspace definition per zome

Whenever running hc generate, I get this warning. It seems like it would be a good idea to generate a top-level Cargo.toml to create a workspace, which will not only squelch this error but help zomes work better with IDEs.

hc g zomes/hosts
> cargo init --lib --vcs none
warning: compiling this new crate may not work due to invalid workspace configuration

current package believes it's in a workspace when it's not:
current:   /Users/michael/Holo/hosting-app/zomes/hosts/code/./Cargo.toml
workspace: /Users/michael/Holo/hosting-app/Cargo.toml

this may be fixable by adding `zomes/hosts/code` to the `workspace.members` array of the manifest located at: /Users/michael/Holo/hosting-app/Cargo.toml
     Created library package

consider unifying __META__ to one place

Currently the META is spread around into each object. We should think about whether in makes more sense to have just a single meta at the top level that maps to the whole tree.

(Sub) Commands for generating entry_types and capabilities?

Another question, regarding CLI tools. It seems it would be best to have a cli command for generating not just a new zome folder, but a new capability within that zome, and a new entry type.
So...

hcdev g(enerate) zome myzome
hcdev g capability myzome mycapability
hcdev g entry_type myzome myentrytype

Or you could pass capability names and entry_type names while generating the zome initially, but it seems you wouldn't always know them ahead of time, so being able to call independently would be very useful

error[E0554]: #![feature] may not be used on the stable release channel

Error installing holochain-cmd with rustc 1.29.0 (aa3ca1994 2018-09-11) on MacOS 10.13.6

Output:

chrisminnick$ cargo install -f --path .
Installing hcdev v0.1.0 (file:///Users/chrisminnick/holochain-cmd)
Updating registry https://github.com/rust-lang/crates.io-index
Updating git repository https://github.com/holochain/holochain-rust
Downloading structopt v0.2.10
Downloading serde_json v1.0.26
Downloading failure v0.1.2
Downloading assert_cmd v0.9.1
Downloading colored v1.6.1
Downloading serde v1.0.75
Downloading serde_derive v1.0.75
Downloading ignore v0.4.3
Downloading dir-diff v0.3.1
Downloading uuid v0.6.5
Downloading tempfile v3.0.3
Downloading semver v0.9.0
Downloading base64 v0.9.2
Downloading structopt-derive v0.2.10
Downloading clap v2.32.0
Downloading syn v0.14.9
Downloading quote v0.6.8
Downloading proc-macro2 v0.4.15
Downloading unicode-xid v0.1.0
Downloading bitflags v1.0.4
Downloading strsim v0.7.0
Downloading ansi_term v0.11.0
Downloading unicode-width v0.1.5
Downloading vec_map v0.8.1
Downloading textwrap v0.10.0
Downloading atty v0.2.11
Downloading libc v0.2.43
Downloading ryu v0.2.6
Downloading indexmap v1.0.1
Downloading itoa v0.4.2
Downloading failure_derive v0.1.2
Downloading backtrace v0.3.9
Downloading synstructure v0.9.0
Downloading cfg-if v0.1.5
Downloading rustc-demangle v0.1.9
Downloading snowflake v1.3.0
Downloading riker v0.1.7
Downloading rust-base58 v0.0.4
Downloading multihash v0.8.0
Downloading lazy_static v1.1.0
Downloading config v0.8.0
Downloading unwrap_to v0.1.0
Downloading num-traits v0.2.5
Downloading num-derive v0.2.2
Downloading riker-default v0.1.7
Downloading futures-preview v0.2.2
Downloading riker-patterns v0.1.7
Downloading chrono v0.4.6
Downloading wasmi v0.3.0
Downloading rand v0.4.3
Downloading log v0.4.4
Downloading bytes v0.4.9
Downloading regex v0.2.11
Downloading time v0.1.40
Downloading num-integer v0.1.39
Downloading toml v0.4.6
Downloading nom v3.2.1
Downloading serde-hjson v0.8.1
Downloading yaml-rust v0.4.0
Downloading memchr v1.0.2
Downloading num-traits v0.1.43
Downloading serde v0.8.23
Downloading linked-hash-map v0.3.0
Downloading regex v0.1.80
Downloading lazy_static v0.2.11
Downloading serde_test v0.8.23
Downloading memchr v0.1.11
Downloading aho-corasick v0.5.3
Downloading regex-syntax v0.3.9
Downloading thread_local v0.2.7
Downloading utf8-ranges v0.1.3
Downloading thread-id v2.0.0
Downloading kernel32-sys v0.2.2
Downloading winapi v0.2.8
Downloading winapi-build v0.1.1
Downloading linked-hash-map v0.5.1
Downloading version_check v0.1.4
Downloading futures-stable-preview v0.2.3
Downloading futures-executor-preview v0.2.2
Downloading futures-core-preview v0.2.3
Downloading futures-async-runtime-preview v0.2.3
Downloading futures-util-preview v0.2.2
Downloading futures-channel-preview v0.2.2
Downloading futures-sink-preview v0.2.2
Downloading futures-io-preview v0.2.2
Downloading either v1.5.0
Downloading num_cpus v1.8.0
Downloading iovec v0.1.2
Downloading byteorder v1.2.6
Downloading thread_local v0.3.6
Downloading utf8-ranges v1.0.1
Downloading aho-corasick v0.6.8
Downloading memchr v2.0.2
Downloading regex-syntax v0.5.6
Downloading ucd-util v0.1.1
Downloading num v0.2.0
Downloading num-complex v0.2.0
Downloading num-bigint v0.2.0
Downloading num-rational v0.2.1
Downloading num-iter v0.1.37
Downloading sha1 v0.5.0
Downloading tiny-keccak v1.4.2
Downloading sha2 v0.7.1
Downloading crunchy v0.1.6
Downloading fake-simd v0.1.2
Downloading digest v0.7.5
Downloading byte-tools v0.2.0
Downloading block-buffer v0.3.3
Downloading generic-array v0.9.0
Downloading typenum v1.10.0
Downloading arrayref v0.3.5
Downloading riker-mapvec v0.1.7
Downloading riker-dispatcher v0.1.7
Downloading riker-timer v0.1.7
Downloading riker-log v0.1.7
Downloading riker-deadletter v0.1.7
Downloading futures-cpupool v0.1.8
Downloading futures v0.1.23
Downloading runtime-fmt v0.3.0
Downloading safemem v0.2.0
Downloading parity-wasm v0.31.3
Downloading nan-preserving-float v0.1.0
Downloading memory_units v0.3.0
Downloading predicates-tree v0.9.0
Downloading escargot v0.3.1
Downloading predicates-core v0.9.0
Downloading predicates v0.9.0
Downloading treeline v0.1.0
Downloading difference v2.0.0
Downloading normalize-line-endings v0.2.2
Downloading regex v1.0.4
Downloading float-cmp v0.4.0
Downloading regex-syntax v0.6.2
Downloading crossbeam v0.3.2
Downloading walkdir v2.2.5
Downloading globset v0.4.1
Downloading same-file v1.0.3
Downloading fnv v1.0.6
Downloading remove_dir_all v0.5.1
Downloading rand v0.5.5
Downloading rand_core v0.2.1
Downloading semver-parser v0.7.0
Compiling winapi-build v0.1.1
Compiling proc-macro2 v0.4.15
Compiling either v1.5.0
Compiling version_check v0.1.4
Compiling libc v0.2.43
Compiling unicode-xid v0.1.0
Compiling winapi v0.2.8
Compiling num-traits v0.2.5
Compiling serde v1.0.75
Compiling serde v0.8.23
Compiling ryu v0.2.6
Compiling typenum v1.10.0
Compiling utf8-ranges v0.1.3
Compiling num-integer v0.1.39
Compiling regex-syntax v0.3.9
Compiling itoa v0.4.2
Compiling num-bigint v0.2.0
Compiling regex v0.2.11
Compiling linked-hash-map v0.5.1
Compiling ucd-util v0.1.1
Compiling indexmap v1.0.1
Compiling lazy_static v0.2.11
Compiling cfg-if v0.1.5
Compiling num-complex v0.2.0
Compiling num-rational v0.2.1
Compiling num-iter v0.1.37
Compiling utf8-ranges v1.0.1
Compiling crunchy v0.1.6
Compiling byteorder v1.2.6
Compiling byte-tools v0.2.0
Compiling futures v0.1.23
Compiling regex v1.0.4
Compiling arrayref v0.3.5
Compiling safemem v0.2.0
Compiling unicode-width v0.1.5
Compiling fake-simd v0.1.2
Compiling failure_derive v0.1.2
Compiling escargot v0.3.1
Compiling runtime-fmt v0.3.0
Compiling fnv v1.0.6
Compiling same-file v1.0.3
error[E0554]: #![feature] may not be used on the stable release channel
--> /Users/chrisminnick/.cargo/registry/src/github.com-1ecc6299db9ec823/runtime-fmt-0.3.0/src/lib.rs:17:1
|
17 | #![feature(fmt_internals)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0554]: #![feature] may not be used on the stable release channel
--> /Users/chrisminnick/.cargo/registry/src/github.com-1ecc6299db9ec823/runtime-fmt-0.3.0/src/lib.rs:18:1
|
18 | #![feature(conservative_impl_trait)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0554]: #![feature] may not be used on the stable release channel
--> /Users/chrisminnick/.cargo/registry/src/github.com-1ecc6299db9ec823/runtime-fmt-0.3.0/src/lib.rs:19:1
|
19 | #![feature(specialization)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0554]: #![feature] may not be used on the stable release channel
--> /Users/chrisminnick/.cargo/registry/src/github.com-1ecc6299db9ec823/runtime-fmt-0.3.0/src/lib.rs:20:1
|
20 | #![feature(print_internals)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0554]: #![feature] may not be used on the stable release channel
--> /Users/chrisminnick/.cargo/registry/src/github.com-1ecc6299db9ec823/runtime-fmt-0.3.0/src/lib.rs:21:1
|
21 | #![feature(rustc_private)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0554]: #![feature] may not be used on the stable release channel
--> /Users/chrisminnick/.cargo/registry/src/github.com-1ecc6299db9ec823/runtime-fmt-0.3.0/src/lib.rs:22:1
|
22 | #![feature(try_from)]
| ^^^^^^^^^^^^^^^^^^^^^

error: aborting due to 6 previous errors

For more information about this error, try rustc --explain E0554.
error: Could not compile runtime-fmt.
warning: build failed, waiting for other jobs to finish...
error: failed to compile `hcdev v0.1.0

Build requires nightly rust

I could not build with a stable rust build. The README should probably mention that nightly rust is required.

Sample error:

error[E0554]: #![feature] may not be used on the stable release channel
  --> /Users/michael/.cargo/registry/src/github.com-1ecc6299db9ec823/runtime-fmt-0.3.0/src/lib.rs:17:1
   |
17 | #![feature(fmt_internals)]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^

Could not compile `hc`.

Hey guys, I am trying to build the latest version on master, but I get the following error:

error[E0658]: The attribute structopt` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
--> src/main.rs:30:1
|
30 | #[structopt(about = "A command line for Holochain")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: add #![feature(custom_attribute)] to the crate attributes to enable

error: aborting due to 22 previous errors
`

All errors are related to this StructOps, that starts with this error:
error: cannot find derive macro StructOpt` in this scope==========> ] 184/185: hc
--> src/main.rs:29:10
|
29 | #[derive(StructOpt)]
| ^^^^^^^^^

`

Should I be using a specific branch?

Cheers!

rename default `bundle.json` file to better name

If we are going to go with a generic name it should probably be package.json or hcpackage.json so as not to make it look like we have an npm bundle.

We might also want to consider going with named files, like myapp.json where myapp is the name of the containing source directory. That way, when unpacking, it could default to creating a directory of that name. (see #6)

generate: add entry definition with sample function

As an hcdev user, I want the generate zome command to create a scaffold in the zome.json file of an entry type with a sample exposed function definition, and also code for that exposed function.

Currently the generate function just creates a bare-bones zome with a "main()" code function that doesn't really make sense, it needs to be fleshed out a bit with a sample entry_types definition.

give fully usable Cargo.toml on `hc generate zomes/x rust`

This is usable:

[package]
  name = "code"
  version = "0.1.0"
  authors = ["Author Name <[email protected]>"]
  edition = "2018"
[dependencies]
  serde = "1.0"
  serde_json = "1.0"
  hdk = { git = "https://github.com/holochain/hdk-rust" }
  serde_derive = "1.0"
  holochain_wasm_utils = { git = "https://github.com/holochain/holochain-rust" , branch = "develop" }
[lib]
  path = "src/lib.rs"
  crate-type = ["cdylib"]

unpack should work when `to` doesn't exist or not specified

You shouldn't have to specify a to when unpacking or at least it should work if the directory doesn't exist, i.e. there should be default behavior. here are some options:

  • use the name of the package file itself which shouldn't be bundle, but rather .json
  • use snake cased version of the name, as the directory name,
  • use the value of to as the directory name if that directory doesn't exist.

this would make unpack feel like the familiar git clone

ignored files

we need to have some kind of .package-ignore that lists what's excluded, for example .DS-Store, etc...

tests for the 'generate' command

currently the tests confirm that the commands run and return success, but they don't actually test what the commands are supposed to have done. I.e. that files got created and such. The tests should actually do that!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.