You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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-ens to support subname and text record lookups
leveraging chain-specific address lookups via ape-ens converter
adding support for this via ape-ens converter (something like "<Contract Type Name>@<ENS Record Name>[:latest]"?)
writing this all up as an EIP and/or ENSIP and going through that process
The text was updated successfully, but these errors were encountered:
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 ofversion
package metadata key (similar to howsetuptools-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"
(oreipXXXX:manifest
?) containing a public location (or locations?) where the fully compiled manifest for that version is published, as well as a text record"types"
(oreipXXXX: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 optionalversion
key to specify a specific version (with"latest"
being the default)Dependencies
Many dependencies here, but most importantly:
ape-ens
to support subname and text record lookupsape-ens
converterape-ens
converter (something like"<Contract Type Name>@<ENS Record Name>[:latest]"
?)The text was updated successfully, but these errors were encountered: