Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Package and Dapp Descriptor Format #82

nmushegian opened this issue Mar 24, 2016 · 3 comments

Package and Dapp Descriptor Format #82

nmushegian opened this issue Mar 24, 2016 · 3 comments


Copy link

@nmushegian nmushegian commented Mar 24, 2016

Package and Dapp Descriptor Format


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".


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:


The dappfile schema is defined here:


Sample implementation here:

Example dappfile

name: mydapp
version: 0.1.0
  sol_sources: contracts
  build: build
  default: morden
       address: 0x0...
       type: MyRegistry
         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.

Copy link

@juanfranblanco juanfranblanco commented Apr 30, 2016

I have started the implementation on the Vs-Code extension for the support of dappfiles for compilation and package dependencies.

This standard makes far much easier to work with complex projects and resolve dependencies.

Copy link

@fulldecent fulldecent commented Mar 22, 2018

@Arachnid You nominated this as an "EIPs that should be merged". Can you please share your notes on that here?

Copy link

@github-actions github-actions bot commented Jan 16, 2022

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

@github-actions github-actions bot added the stale label Jan 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants