Skip to content
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

deps: Unpin Solana dependencies #74

Merged
merged 1 commit into from
Jan 13, 2025
Merged

Conversation

joncinque
Copy link
Contributor

Problem

It's very useful to run downstream tests with newer versions of the Solana crates to catch unwanted breakage. Mollusk pins some of its Solana crate dependencies to 2.1.0.

The token repo uses mollusk for its testing framework, but because of the pinning in mollusk, it's impossible to run downstream tests on token with newer versions of the monorepo.

Summary of changes

This might be totally off-base, and I might be missing something important, but it'll be way more flexible and easier if mollusk unpins its dependencies.

@joncinque joncinque changed the title dwps: Unpin Solana dependencies deps: Unpin Solana dependencies Jan 9, 2025
#### Problem

It's very useful to run downstream tests with newer versions of the
Solana crates to catch unwanted breakage. Mollusk pins some of its
Solana crate dependencies to 2.1.0.

The token repo uses mollusk for its testing framework, but because of
the pinning in mollusk, it's impossible to run downstream tests on token
with newer versions of the SDK.

#### Summary of changes

This might be totally off-base, and I might be missing something
important, but it'll be way more flexible and easier if mollusk unpins
its dependencies.
Copy link
Collaborator

@buffalojoec buffalojoec left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only thing we have to be careful of here is the fact that APIs within solana-program-runtime do not respect semver, and therefore can change and break Mollusk.

We can ship this for the main release line, but I think I'll also cut a solana-2.1 release line where versions are aligned with Solana/Agave versions, in case any API changes break.

For example, I know a few fields on ComputeBudget changed between some 2.1.x and 2.1.y versions.

EDIT: As a side note, the work I'm doing with porting SolFuzz-Agave into SVM should solve this, since it shifts the onus for keeping the test entrypoint in line with changes to solana-program-runtime into the validator source.

@joncinque
Copy link
Contributor Author

Gotcha, it's your library, so I'll let you decide the best course of action. I'm surprised there were breaking changes in a patch release 😞

@buffalojoec
Copy link
Collaborator

Gotcha, it's your library, so I'll let you decide the best course of action. I'm surprised there were breaking changes in a patch release 😞

Yeah it's too bad, but let's ship it 🚢 and see what happens! We might be far enough along at this point.

@buffalojoec buffalojoec merged commit 5fe33b0 into anza-xyz:main Jan 13, 2025
4 checks passed
@joncinque joncinque deleted the unpin branch January 13, 2025 16:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants