Dynamic Versioning and Deployments #2298
Description
Describe
Been thinking a lot about managing deployments, and think there is a way to publish schema using ENS to help track both releases (e.g. package manifests as content-address URIs) and deployments (leveraging ENS's ability to describe the ABI and addresses for the deployment on multiple chains)
Specification
In your ape-config.yaml, add support for an object {"ens": "<ENS Record Name>"} inside of version package metadata key (similar to how setuptools-scm configuration works w/ dynamic)
If that key is provided (and the ape-ens plugin is installed) check what the value of the text record "latest" (should this become an EIP to namespace? e.g. eipXXXX:version instead?) to find a string value (which should adhere to Semantic Versioning) for the latest version of that package. That record should correspond with a subname (releative to the given ens record where "latest" was found) in RDNS-like ordering (e.g. "vX.Y.Z" would be Z.Y.vX.`)
The entry at that given location would then contain a text record "manifest" (or eipXXXX:manifest?) containing a public location (or locations?) where the fully compiled manifest for that version is published, as well as a text record "types" (or eipXXXX:types?) which is an array of strings for all the types available in the compiled manifest. For each string value in "types", there should be an additional subname for it (e.g. <Contract Type Name>.Z.Y.vX.<ENS Record Name>) at that record which contains commonly useful records like ABI (there is already direct support for this within ENS today), and then the address of each deployment on whatever chain it has been deployed too (ENS also already has support for this today)
Similarly, later on we can allow specifying a dependency type ens: "<ENS Record Name>" in your project's dependencies that can be used to look up already published manifests in a similar way, with an optional version key to specify a specific version (with "latest" being the default)
Dependencies
Many dependencies here, but most importantly:
- ability to create a publish-able manifest (this may require v4 revision EIP, or a new iteration on the concept leveraging a filesystem-like structure instead of JSON)
- updates to
ape-ensto support subname and text record lookups - leveraging chain-specific address lookups via
ape-ensconverter - adding support for this via
ape-ensconverter (something like"<Contract Type Name>@<ENS Record Name>[:latest]"?) - writing this all up as an EIP and/or ENSIP and going through that process