"contract_types" to "contracts"

[fubuloubu]

Mostly just a semantics thing, why is it "contract_types" instead of something simpler like "contracts"?

Solidity's JSON output puts them into a "contracts" object. Might make for easier compatibility.

[pipermerriam]

Then intent was to differentiate between instances and types. Using the name contracts would be fine, but I think it is more likely to be confused with being the container for deployed contract instances without the suffix.

[fubuloubu]

Why not just do "instances"?

[pipermerriam]

do you mean renaming deployments to instances?

Because they are not strictly a list of contract instances but a mapping of chain URI -> Name -> Instance and so deployments seemed like a more appropriate name.

[fubuloubu]

Yeah, that's definitely not what we'd want to do. Deployments makes more sense.

You are saying contracts might get confused with deployments i.e. the contract instances that have been deployed to the network? I think it's bit semantics, contract_types sounds like there are categories of contracts that exist.

Ultimately, someone who is using an ethpm package should know the difference between a contract and a deployment.

[pipermerriam]

The reason we went with the suffix is that the word contract is overloaded.

contract Token {
   ...
}

• the code above defines the Token contract.
• the contract deployed to 0x1234abcd....

So we chose to add a suffix. I think removing the suffix is worse than the potential for people to confuse the term types to mean "categories". I'd be good entertaining alternate suffixes, or ways to deliniate the difference between a contract as a deployed entity, and a contract as defined in source code. But just using the term *contracts` feels overloaded to me.

[fubuloubu]

Fair enough, that is a valid point. Maybe compiled_contracts?

In one of my projects, I was creating a contracts.min.json that removed all of the contracts that solidity outputs and only kept the ones my platform was exposing for endpoint use. This made my front end code a bit smaller when it was downloading that as an asset along with the compiled front end code. Would be interesting if compiled_contracts were the subset that the package was exposing for use, whereas the source might define more intermediate and/or testing contracts.