Conversation
grod220
force-pushed
the
3.0-deps
branch
5 times, most recently
from
520811a to
44cc9b4
Compare
| # TODO: Remove after agave/mollusk/stake-program depend on aligned StakeHistory version | ||
| # Either solana-stake-interface v3 or new solana-stake-history crate | ||
| solana-stake-interface-v2 = { package = "solana-stake-interface", version = "2.0.1" } |
There was a problem hiding this comment.
Points raised anza-xyz/mollusk#228 (review)
StakeHistory sysvar is creating a dependency chain between
stake interface -> agave -> mollusk -> stake program
Can be resolved by:
- Agave libraries shipping with updated solana-stake-inteface dependency
- Or even better, moving solana-stake-history to its own crate.
There was a problem hiding this comment.
We could potentially move stake history to its own crate, since it likely won't change as often.
Note that it wouldn't really help right now since it still depends on solana-sysvar, which depends on solana-account / solana-rent, which is at the root of all this annoyance.
Two versions of a crate is totally fine if there's no other way
There was a problem hiding this comment.
SysvarSerialize removed from stake & mollusk. Now just agave to go.
| solana-rent = "3.0.0" | ||
| solana-security-txt = "1.1.2" | ||
| solana-stake-interface = { version = "2", features = ["bincode", "borsh", "sysvar"] } | ||
| solana-stake-interface = { path = "../interface", version = "3.1.0", features = ["bincode", "borsh", "sysvar"] } |
There was a problem hiding this comment.
iirc there was a reason we stopped using path in favor of version but i can never remember what it was... maybe @joncinque does? or it could have been febo, i dont think it was me
There was a problem hiding this comment.
Oh wait a sec: #79 (comment)
I suppose we want to keep it detached to update the interface & program independently? Why is that desirable though?
There was a problem hiding this comment.
The chain of dependencies goes: program -> agave -> interface
This means we can't update agave until the interface is updated, and we can't update the program until agave is updated.
The whole point of separating out the interface was to remove the circular dependency between the program and agave.
As for the dep here, it's probably better to use the local one to help catch issues right away. But it does mean we can also accidentally publish the program crate without the interface and cause issues.
But I don't feel too strongly either way.
There was a problem hiding this comment.
In the worst case, I think someone attempts a stake-program publish when the used stake-interface version isn't published. That seems worthwhile as it requires interface changes to be handled in the program crate as they are changed versus lagging program-sync PRs.
That said, it's easy enough to drop the path = "../interface" if we run into issues later.
3 participants
The interface is on v3 but program depends on v2. While rebasing #152 to the latest main, found this to be a blocker.