Package and Dapp Descriptor Format
Abstract
Successful languages have package management tools which greatly simplify code sharing, which contributes to network effect.
The Ethereum ecosystem is somewhat unique in that everyone shares a global runtime environment, so addresses are both "code-like" and "object-like".
Motivation
We want to ensure we can support the whole spectrum of Solidity packages, especially those that allow working with existing systems:
- Simple static libraries which make no reference to any objects on any chain (ie
Math)
- Packages which describe singleton dapps (they ship address references and type info, but don't intend for people to re-use the solidity code, like actual Solidity libraries (
string)).
- Packages which describe singleton dapps, with extra support code for interacting with the system (eg something that interacts with a registry)
- Packages which describe dapp "types" which you can deploy, like when an app is too large to build via a factory or requires a complex deployscript (eg a Token system that separates datastore/controller/frontend).
The result is a descriptor file called a dappfile which is similar to npm's package.json but with special attention to handling addresses with special meaning.
dappfiles can be modified in a structured way with "deploy scripts", which is out of scope for this ERC but is described here: https://github.com/nexusdev/dapple/blob/master/doc/deployscript.md
Specification
The dappfile schema is defined here: https://github.com/nexusdev/dapple/blob/master/specs/dappfile.schema.json
Implementation
Sample implementation here: https://github.com/nexusdev/dapple
Example dappfile
name: mydapp
version: 0.1.0
layout:
sol_sources: contracts
build: build
environments:
default: morden
morden:
my_dapp_registry:
address: 0x0...
type: MyRegistry
ethereum:
my_dapp_registry:
addresss: 0x1...
type: MyRegistry
Things to discuss
I propose we start by polling to see if there are any unusual use cases which do not fit into the "set of solidity files, plus named sets of sets of named addresses" model.
Package and Dapp Descriptor Format
Abstract
Successful languages have package management tools which greatly simplify code sharing, which contributes to network effect.
The Ethereum ecosystem is somewhat unique in that everyone shares a global runtime environment, so addresses are both "code-like" and "object-like".
Motivation
We want to ensure we can support the whole spectrum of Solidity packages, especially those that allow working with existing systems:
Math)string)).The result is a descriptor file called a
dappfilewhich is similar to npm'spackage.jsonbut with special attention to handling addresses with special meaning.dappfiles can be modified in a structured way with "deploy scripts", which is out of scope for this ERC but is described here: https://github.com/nexusdev/dapple/blob/master/doc/deployscript.mdSpecification
The
dappfileschema is defined here: https://github.com/nexusdev/dapple/blob/master/specs/dappfile.schema.jsonImplementation
Sample implementation here: https://github.com/nexusdev/dapple
Example dappfile
Things to discuss
I propose we start by polling to see if there are any unusual use cases which do not fit into the "set of solidity files, plus named sets of sets of named addresses" model.