transfer-hook-interface: Remove solana-program dependency #7442
Conversation
|
Oof, never mind, the CI failure here is very legit. The token-2022 program tests rely on using the "native builtin" hack, where solana-program-test turns a provided function pointer into a program processor. This relies on the syscall stubs, which are not used in the new To properly test all the transfer hook behavior, we'll need to turn all of the test processors into built BPF programs. Edit: moving to draft for now |
What's the plan for this, create a "test programs" directory? Could get a little messy. |
|
Yeah that's what I've been doing. A directory of test programs, with built programs in tests/fixtures. I was thinking that we'll need to do this no matter what, if we ever want to move away from solana-program-test, so it's probably worth biting the bullet. It comes out to 4 extra test programs. Other than the extra directories and workspace entries, do you have any other concerns? |
No, I don't think so, it was mainly the workspace members and determining how often we need to build new fixtures, which shouldn't be often. |
|
All right, it's all good! Let me know how you like the structure |
token/program-2022-test/transfer-hook-test-programs/downgrade/src/lib.rs
Outdated
Show resolved
Hide resolved
#### Problem The transfer-hook-interface pulls in solana-program, but it doesn't need to. #### Summary of changes Use the component crates. The only breaking change is the re-exports. It still uses a dev-dependency on solana-program since the system program id isn't available yet outside of solana-program.
mergify
bot
dismissed
buffalojoec’s stale review
Pull request has been modified.
Problem
The transfer-hook-interface pulls in solana-program, but it doesn't need to.
Summary of changes
Use the component crates. The only breaking change is the re-exports. It still uses a dev-dependency on solana-program since the system program id isn't available yet outside of solana-program.