Consider re-organizing hierarchy of "deployments" key

[davesque]

It seems like the hierarchy of the "deployments" key might be a little inconvenient to handle for package tooling authors.

Currently, the "deployments" key is structured like so:

{
  "package_name": "greeter",
  ...
  "deployments": {
    "blockchain://.../block/...": {
      "Greeter": {
        ..
      }
    }
  },
  ...
}

The fact that blockchain URIs are used to categorize deployments has a drawback. From the point of view of a package tool's API, it would be nice to be able to have some method, which we could call get_deployment, that would accept a string argument that is a unique key for that deployment in the package. Since blockchain URIs are the first level of organization in the "deployments" key, the deployment labels which appear under them need not be unique. This makes it harder to provide such a get_deployment method since you might need to resolve ambiguities in the naming of deployments under the blockchain keys.

Perhaps a hierarchy like this could be more convenient for implementing that functionality:

{
  "package_name": "greeter",
  ...
  "deployments": {
    "Greeter": {
      "blockchain": "blockchain://.../block/...",
      ..
    }
  },
  ...
}

With this approach, the "Greeter" key becomes a unique handle to that deployment within the package. Tooling authors can then use simple dictionary-like data structures to keep track of deployed instances and there's no need to resolve any ambiguities between similarly named deployments.

Thoughts?

[pipermerriam]

The current design is based on an assumption that get_deployment will always be operating in the context of a specific chain. In this model, the blockchain URI is the first level of filtering that must be done because we only want deployments from the chain that we are operating on.

I believe that the spec states that the keys within deployments must be unique, so we still can have a get_deployments(unique_key) which executes the following logic which I believe is very straight forward to implement.

• Filter deployments for matching blockchain URIs, error if not exactly 1
• Look for the unique_key within that section of the deployments, error if not exactly 1
• grab the address.

[davesque]

That makes sense. I had forgotten that this get_deployment method would probably be accessed as w3.pm.get_deployment and w3 would specify the chain. I'll close this.