DNA manifest file (app.json) explicit zome references #1300
Description
Proposal
Add a "zomes" field to the DNA manifest (app.json / manifest.json) which explicitly contains info about zome location, like this:
{
"zomes": {
"blog": "zomes/blog",
"another": "some/other/zomes/another"
}
}The benefits are several:
1. Freedom of project directory structure
Users could choose a less deeply-nested directory structure, i.e. this:
project/
dna-src/
app.json
zomes/
blog/
code/
src/
lib.rs
could be replaced with this (or any other conceivable directory structure):
project/
hcdna.json
zome-blog/
code/
src/
lib.rs
So, this shaves off two layers of directory nesting. ("dna-src" is a convention we use, but I think it's primarily because of the current prescriptive directory structure.)
Note: To ensure that a package can be unpackaged into its original directory structure, the zome paths must be constrained to be subdirectories of the directory containing the manifest file. (Thanks for pointing out @zippy)
2. Remote zome dependencies
This would also open the possibility of treating the app.json as similar to a package.json or Cargo.toml file for zomes. Rather than a local path, a remote URL could be listed, or even a HCHC hash. For third-party zomes, developers won't want to maintain a local copy
3. Remote DNA dependencies
Currently, for a given project containing DNA source code, there is no sure way to tell which directory to run hc package in, because it's not guaranteed that the root of the project is also the DNA source root.
Using explicit zome directory references like this, it is clear exactly how to build the project. That means that for hApp developers, there can be tooling that points either to a built DNA package (foo.dna.json) -OR- a remote source code repository. This would be helpful for development purposes, where a dev can point to a GH branch when testing a DNA with their team, rather than having to package and upload a .dna.json for every change.
We should also probably rename "app.json" to something more globally recognizable like "hcdna.json" or something, since this would be the canonical way to identify a source code repo as containing DNA source code.