-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Isolate Python SDK snippets from PR #6356 #6788
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! @clay-aptos want to do a quick run through of the documentation?
# :!:>manifest | ||
[package] | ||
name = 'UpgradeAndGovern' | ||
version = '1.0.0' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rather than versioning, could we just label these with more expressive names?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the tutorial demonstrates upgrading a package with a multisig, it looks like both need to have the same package.name
field in the manifest (otherwise it wouldn't be an upgrade, just publishing two packages with different names that happen to have similar code).
I did experiment with setting package.version
to a non-SemVer schema, e.g. version = 'Genesis'
and version = 'Upgrade'
, but the compiler threw:
{
"Error": "Move compilation failed: Error parsing '[package]' section of manifest: Version is malformed. Versions must be of the form <u64>.<u64>.<u64>, but found 'Genesis'"
}
So I settled on simply placing the packages in the two directories:
move-examples/upgrade_and_govern/genesis
move-examples/upgrade_and_govern/upgrade
How does this sound?
@@ -0,0 +1,18 @@ | |||
// :!:>script | |||
script { | |||
use upgrade_and_govern::parameters; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would avoid placing multiple scripts in the same package and entirely from modules, reason being, they don't keep their names as they get compiled, so you don't know which script is which.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
they don't keep their names as they get compiled, so you don't know which script is which
@davidiw I'm a bit confused by this guidance, as the upgrade package has two scripts, set_and_transfer.move
and set_only.move
, which respectively compile into set_and_transfer.mv
and set_only.mv
as expected.
I suspect the hypothetical name loss you refer to is a result of using main
as the main function name for every script in a Move package:
script {
fun main( // <- main function name
// ^ this PR uses either `set_only` or `set_and_transfer`, but
// name loss would result if both had `main`
...
) {
...
}
}
This is analogous to using the same module definition block across multiple module .move
files
module named_address::a_repeated_module_name {
// ^ this compiles into `a_repeated_module_name.mv`
// regardless of the `.move` filename
...
}
What are your thoughts?
@@ -79,6 +80,37 @@ def public_key(self) -> ed25519.PublicKey: | |||
return self.private_key.public_key() | |||
|
|||
|
|||
class RotationProofChallenge: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so I was suggesting that we emit out a chunk of bytes from say
let rotation_msg = bcs::to_bytes(&rotation_proof).unwrap(); |
and dumping this to hex and importing that hex string here... that way we can be confident that it works as expected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@davidiw how does this look?
The classes have been verified e2e on devnet using the example script broken down in the tutorial, so I just emitted some bytes and made a test for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks so much, Al. The docs LGTM with some tiny changes I made in direct commits and a fix to the examples directory I flag in a comment here. Thanks again! I look forward to adding this to our Community Highlights list!
Definitely! All done. Thanks again, @alnoki ! |
Hi @alnoki , I am noting we launched this: And would love to have this online. Please let me know how O can help. Thanks! |
@clay-aptos thank you for your patience during all of the delays during Aptos Week at Mountain DAO and then ETH Denver. I've about 80% done with a commit that addresses comments from you and @davidiw above and am hoping to push in the next few days or so. |
@davidiw @clay-aptos I believe I've addressed your review comments above: is there anything else you need to move this along? |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks!!
@@ -79,6 +80,37 @@ def public_key(self) -> ed25519.PublicKey: | |||
return self.private_key.public_key() | |||
|
|||
|
|||
class RotationProofChallenge: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great
print(f"Bob: {bob.public_key()}") | ||
print(f"Chad: {chad.public_key()}") # <:!:section_1 | ||
|
||
wait() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's the point of these waits? we want these to run in a test environment... we need to quickly follow up this PR with something that validates this on every PR -- these quickly bitrot or start failing due to other ninjas
124bf3c
to
3bbd3f3
Compare
realized the tutorial is interactive... this will bitrot, we need to consider some other means, even if that is that we keep pre-compiled versions around. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
✅ Forge suite
|
✅ Forge suite
|
✅ Forge suite
|
Just noting we are announcing and linking in: |
Per request of @davidiw in #6356 , isolates multisig Python SDK snippets from AMEE content.
The following commands were run in below paths:
aptos-core/:
aptos-core/developer-docs-site/:
aptos-core/ecosystem/python/sdk:
Modifications to
bcs.py
as a result ofmake fmt
were disregarded since the file's contents were not modified per this PR.