aptos-core
aptos-core copied to clipboard
[aptos-cli] Use onchain packages instead of git packages
@wrwg looks like the aptos path doesn't work for me in my local testing. Need to probably debug it
@wrwg looks like the
aptospath doesn't work for me in my local testing. Need to probably debug it
Alright I think it needs a smoke test. Parts of this is tested e2e but not all of it. I will add one these days and debug.
@wrwg looks like the
aptospath doesn't work for me in my local testing. Need to probably debug itAlright I think it needs a smoke test. Parts of this is tested e2e but not all of it. I will add one these days and debug.
Wait a sec. I think I know what the problem is.
@wrwg looks like the
aptospath doesn't work for me in my local testing. Need to probably debug itAlright I think it needs a smoke test. Parts of this is tested e2e but not all of it. I will add one these days and debug.
Wait a sec. I think I know what the problem is.
This has not been called
This looks like it's called before every command, but let me see if I move it around it will fix some things
This has not been called
This looks like it's called before every command, but let me see if I move it around it will fix some things
One can see that the issue if somewhere in the logs it complains about an unknown property in the Move.toml. That is the new property upgrade_policy in the toml. As long as that registration has not happened, this warning will appear.
Feels like there's probably three possibilities here:
- Github
- Local checkout
- Onchain
I'm not sure it is safe to prefer one over the other. Both this and the current approach are problematic for testing or devs without network access.
The most reliable you can do is the chain URL. While it requires to be online, this is only the case for the initial setup. After that a local cache exists for the package which will not be updated until you ask for it (move clean). The later is possible because we never have breaking changes -- every older metadata about the chain is valid as long as you don't miss any new features.
Feels like there's probably three possibilities here:
- Github
- Local checkout
- Onchain
I'm not sure it is safe to prefer one over the other. Both this and the current approach are problematic for testing or devs without network access.
The most reliable you can do is the chain URL. While it requires to be online, this is only the case for the initial setup. After that a local cache exists for the package which will not be updated until you ask for it (
move clean). The later is possible because we never have breaking changes -- every older metadata about the chain is valid as long as you don't miss any new features.
We probably, however, need to revisit all this caching code considering different networks addressed simultaneously from a dev box (so some kind of chain profiles). I think @gregnazario is already looking into this.
Feels like there's probably three possibilities here:
- Github
- Local checkout
- Onchain
I'm not sure it is safe to prefer one over the other. Both this and the current approach are problematic for testing or devs without network access.
The most reliable you can do is the chain URL. While it requires to be online, this is only the case for the initial setup. After that a local cache exists for the package which will not be updated until you ask for it (
move clean). The later is possible because we never have breaking changes -- every older metadata about the chain is valid as long as you don't miss any new features.We probably, however, need to revisit all this caching code considering different networks addressed simultaneously from a dev box (so some kind of chain profiles). I think @gregnazario is already looking into this.
I'm not doing any more looking into packages right now. Just making it so the git packages properly refresh during caching
can we make this happen?
can we make this happen?
The remaining problem was that Greg and I discussed what we do with existing Move.toml which points to a file. Lets say the Move.toml of aptos-framework points to aptos-stdlib on disk. Now we publish this to chain. Should the dependencies of the Move.toml be automatically upgraded to also point on-chain? Greg was suggesting yes. I took a look at it but it appeared a bit odd to rewrite those deps. Another position would be that aptos-framework should already by default refer to on-chain aptos-stdlib. But this doesn't reflect how we develop.
So its a bit of an open conceptual (and coding) question. Auditing stopped me from looking further. Note aptos move download can be used today to get packages from chain.
This issue is stale because it has been open 45 days with no activity. Remove the stale label, comment or push a commit - otherwise this will be closed in 15 days.
Closing for now, as we need to work through other ways to handle these onchain dependencies