Deprecate re-exports more loudly #151

joncinque · 2025-04-30T18:03:54Z

Problem

There are many different crates and types that we would like to remove from the sdk, but they are still re-exported from solana-sdk and solana-program. The re-exports have a #[deprecated(...)] attribute, but they aren't flagged to downstream users.

Summary of changes

Make the re-export deprecations louder by creating a deprecated module and re-exporting from in there.

These are the types affected

DecodeError: this trait isn't all that useful, and is set to be removed entirely with remove solana-decode-error #104, so deprecate it here

These are the crates to no longer re-export from solana-program because they will be moved to program-specific repos:

address_lookup_table -> solana_address_lookup_table_interface
bpf_loader_upgradeable -> solana_loader_v3_interface
loader_upgradeable_instruction -> solana_loader_v3_interface::instruction
loader_v4 -> solana_loader_v4_interface
loader_v4_instruction -> solana_loader_v4_interface::instruction
nonce -> solana_nonce
feature -> solana_feature_gate_interface
loader_instruction -> solana_loader_v2_interface
vote -> solana_vote_interface
stake -> solana_stake_interface
stake_history -> solana_stake_interface::stake_history
system_instruction -> solana_system_interface
system_program -> solana_sdk_ids::system_program (not sure about this one)

Separately, solana_message and solana_sanitize are no longer re-exported. They never quite fit in solana_program, and caused more annoyance than anything else. The re-exports remain in solana_sdk.

solana-decode-error will be removed entirely, so its deprecation is louder too.

For solana-sdk, there are many types that just don't belong, so stop re-exporting these:

commitment_config -> solana_commitment_config
genesis_config -> solana_genesis_config
hard_forks -> solana_hard_forks
rent_collector -> solana_rent_collector
alt_bn128 -> solana_bn254
client -> solana_client_traits
compute_budget -> solana_compute_budget_interface
derivation_path -> solana_derivation_path
ed25519_instruction -> solana_ed25519_program
nonce_account -> solana_nonce_account
packet -> solana_packet
poh_config -> solana_poh_config
quic -> solana_quic_definitions
rent_debits -> solana_rent_debits
secp256k1_instruction -> solana_secp256k1_program
secp256k1_recover -> solana_secp256k1_recover
system_transaction -> solana_system_transaction
exit -> solana_validator_exit

I ran this branch against agave, and there won't be too many changes required. Let me know if you want to add or remove any other re-exports, these seemed like the most sensible.

#### Problem There are many different crates and types that we would like to remove from the sdk, but they are still re-exported from solana-sdk and solana-program. The re-exports have a `#[deprecated(...)]` attribute, but they aren't flagged to downstream users. #### Summary of changes Make the re-export deprecations louder by creating a deprecated module and re-exporting from in there. These are the types affected * `DecodeError`: this trait isn't all that useful, and is set to be removed entirely with anza-xyz#104, so deprecate it here These are the crates to no longer re-export from solana-program because they will be moved to program-specific repos: * `address_lookup_table` -> `solana_address_lookup_table_interface` * `bpf_loader_upgradeable` -> `solana_loader_v3_interface` * `loader_upgradeable_instruction` -> `solana_loader_v3_interface::instruction` * `loader_v4` -> `solana_loader_v4_interface` * `loader_v4_instruction` -> `solana_loader_v4_interface::instruction` * `nonce` -> `solana_nonce` * `feature` -> `solana_feature_gate_interface` * `loader_instruction` -> `solana_loader_v2_interface` * `vote` -> `solana_vote_interface` * `stake` -> `solana_stake_interface` * `stake_history` -> `solana_stake_interface::stake_history` * `system_instruction` -> `solana_system_interface` * `system_program` -> `solana_sdk_ids::system_program` (not sure about this one) Separately, `solana_message` and `solana_sanitize` are no longer re-exported. They never quite fit in `solana_program`, and caused more annoyance than anything else. The re-exports remain in `solana_sdk`. `solana-decode-error` will be removed entirely, so its deprecation is louder too. For `solana-sdk`, there are many types that just don't belong, so stop re-exporting these: * `commitment_config` -> `solana_commitment_config` * `genesis_config` -> `solana_genesis_config` * `hard_forks` -> `solana_hard_forks` * `rent_collector` -> `solana_rent_collector` * `alt_bn128` -> `solana_bn254` * `client` -> `solana_client_traits` * `compute_budget` -> `solana_compute_budget_interface` * `derivation_path` -> `solana_derivation_path` * `ed25519_instruction` -> `solana_ed25519_program` * `nonce_account` -> `solana_nonce_account` * `packet` -> `solana_packet` * `poh_config` -> `solana_poh_config` * `quic` -> `solana_quic_definitions` * `rent_debits` -> `solana_rent_debits` * `secp256k1_instruction` -> `solana_secp256k1_program` * `secp256k1_recover` -> `solana_secp256k1_recover` * `system_transaction` -> `solana_system_transaction` * `exit` -> `solana_validator_exit`

t-nelson · 2025-04-30T22:06:07Z

sdk/src/lib.rs

+}
+#[deprecated(since = "2.2.0", note = "Use `solana-message` crate instead")]
+pub use solana_message as message;
+#[deprecated(since = "2.3.0", note = "Use `solana-nonce` crate instead")]


Suggested change

#[deprecated(since = "2.3.0", note = "Use `solana-nonce` crate instead")]

#[deprecated(since = "2.3.0", note = "Use `solana-system-interface::nonce` crate instead")]

half of me wants this. other half wants to leave it separate to ease removal

It's already in a separate crate for now, but we could certainly merge them later.

t-nelson · 2025-04-30T22:07:16Z

sdk/src/lib.rs

+    #[allow(deprecated)]
+    pub use solana_program::nonce::*;
+}
+#[deprecated(since = "2.3.0", note = "Use `solana-sdk-ids` crate instead")]


this crate feels like a mistake. I'd rather have individual solana_x_interface::program than a junk drawer crate

I completely agree that theoretically we shouldn't need this, but you'd be surprised how many times someone just needs a pubkey and nothing else. We can certainly work towards deprecating it either way.

could we not get there with features?

Maybe, but it does get tricky because features should be additive. If I just want a pubkey from a crate then, all of the other functionality would be enabled on a feature, and that can get gross

i guess i was thinking something like...

[features] full = [] # everything but the declare_id!() behind this default = [ "full" ]

then if i only want pubkey...

[dependencies] solana_crate = { version = "x.y.z", default-features = false }

sdk/src/lib.rs

t-nelson · 2025-04-30T22:15:37Z

sdk/src/lib.rs

-#[deprecated(since = "2.2.0", note = "Use `solana-nonce-account` crate instead")]
-pub use solana_nonce_account as nonce_account;
+#[deprecated(since = "2.3.0", note = "Use `solana-nonce-account` crate instead")]
+pub mod nonce_account {


wouldn't solana_nonce::state be more consistent?

This one's also a bit annoying, it's mostly helpers for working with solana_account types, and not actually used by the system program implementation, except in tests.

We could potentially add it to solana_nonce in the future though

ah right. these are actually my fault iirc. could deprecate them entirely in theory. maybe to {solana_system_interface::,solana_}nonce::account perhaps featurized to discourage future usage

Since it's already in a separate crate, we could just stop using it downstream, then we can remove the crate entirely

sdk/src/lib.rs

t-nelson · 2025-04-30T22:18:14Z

sdk/src/lib.rs

-#[deprecated(since = "2.2.0", note = "Use `solana-secp256k1-program` crate instead")]
+#[deprecated(since = "2.3.0", note = "Use `solana-secp256k1-program` crate instead")]
 #[cfg(feature = "full")]
-pub use solana_secp256k1_program as secp256k1_instruction;
-#[deprecated(since = "2.1.0", note = "Use `solana-secp256k1-recover` crate instead")]
-pub use solana_secp256k1_recover as secp256k1_recover;
+pub mod secp256k1_instruction {
+    pub use solana_secp256k1_program::*;
+}
+#[deprecated(since = "2.3.0", note = "Use `solana-secp256k1-recover` crate instead")]
+pub mod secp256k1_recover {
+    pub use solana_secp256k1_recover::*;
+}


these would also be more consistent as solana_*_interface?

solana-secp256k1-program can do the same as solana-ed25519-program.

The recover crate is a bit strange, since it's just one syscall and a fallback implementation for non-solana targets. I'd prefer to keep it as is since it has some crypto deps.

imo we need to work toward a consistent interface here. absurd that there's a Precompile trait and that there's like zero consistency between the implementations

Yep, agreed big-time

t-nelson · 2025-04-30T22:18:52Z

sdk/src/lib.rs

    note = "Use `solana-system-transaction` crate instead"
 )]
-pub use solana_system_transaction as system_transaction;
+pub mod system_transaction {


worthless helper is worthless 🪓

t-nelson · 2025-04-30T22:45:22Z

there are also a few other things we should kill

solana_sdk::saturating_add_assign!() can be replaced by std::num::Saturating

solana_sdk::program_utils::limited_deserialize needs to go, but i haven't investigated why we changed the interface. i vaguely remember questioning why it exists at all

solana_sdk::rpc_port should never have existed

anything that lives exclusively in solana-sdk should be gone

apfitzge

tx-metadata changes look good to me.

joncinque

Thanks for the review! To address your points:

solana_sdk::saturating_add_assign!() can be replaced by std::num::Saturating

Done, but it's gonna be loud in agave (145 uses)

solana_sdk::program_utils::limited_deserialize needs to go, but i haven't investigated why we changed the interface. i vaguely remember questioning why it exists at all

I'll make the deprecation louder, it's totally unused in agave right now

solana_sdk::rpc_port should never have existed

It's still used unfortunately, but I can add it to solana-rpc-client-api or just locally define them wherever they're used in agave.

joncinque · 2025-05-01T22:54:19Z

sdk/src/lib.rs

+}
+#[deprecated(since = "2.2.0", note = "Use `solana-message` crate instead")]
+pub use solana_message as message;
+#[deprecated(since = "2.3.0", note = "Use `solana-nonce` crate instead")]


It's already in a separate crate for now, but we could certainly merge them later.

joncinque · 2025-05-01T22:55:11Z

sdk/src/lib.rs

+    #[allow(deprecated)]
+    pub use solana_program::nonce::*;
+}
+#[deprecated(since = "2.3.0", note = "Use `solana-sdk-ids` crate instead")]


I completely agree that theoretically we shouldn't need this, but you'd be surprised how many times someone just needs a pubkey and nothing else. We can certainly work towards deprecating it either way.

sdk/src/lib.rs

joncinque · 2025-05-01T22:58:45Z

sdk/src/lib.rs

 #[cfg(feature = "full")]
-#[deprecated(since = "2.2.0", note = "Use `solana-ed25519-program` crate instead")]
-pub use solana_ed25519_program as ed25519_instruction;
+#[deprecated(since = "2.3.0", note = "Use `solana-ed25519-program` crate instead")]


This one's a bit annoying. The current crate is solana-ed25519-program, and it contains the instruction and the verification code.

However, the verification code has been deprecated in favor of agave_precompiles. Once we remove the verification code from solana-ed25519-program, we can just rename the crate to solana-ed25519-interface. What do you think?

joncinque · 2025-05-01T23:04:22Z

sdk/src/lib.rs

-#[deprecated(since = "2.2.0", note = "Use `solana-nonce-account` crate instead")]
-pub use solana_nonce_account as nonce_account;
+#[deprecated(since = "2.3.0", note = "Use `solana-nonce-account` crate instead")]
+pub mod nonce_account {


This one's also a bit annoying, it's mostly helpers for working with solana_account types, and not actually used by the system program implementation, except in tests.

We could potentially add it to solana_nonce in the future though

sdk/src/lib.rs

joncinque · 2025-05-01T23:16:32Z

sdk/src/lib.rs

-#[deprecated(since = "2.2.0", note = "Use `solana-secp256k1-program` crate instead")]
+#[deprecated(since = "2.3.0", note = "Use `solana-secp256k1-program` crate instead")]
 #[cfg(feature = "full")]
-pub use solana_secp256k1_program as secp256k1_instruction;
-#[deprecated(since = "2.1.0", note = "Use `solana-secp256k1-recover` crate instead")]
-pub use solana_secp256k1_recover as secp256k1_recover;
+pub mod secp256k1_instruction {
+    pub use solana_secp256k1_program::*;
+}
+#[deprecated(since = "2.3.0", note = "Use `solana-secp256k1-recover` crate instead")]
+pub mod secp256k1_recover {
+    pub use solana_secp256k1_recover::*;
+}


solana-secp256k1-program can do the same as solana-ed25519-program.

The recover crate is a bit strange, since it's just one syscall and a fallback implementation for non-solana targets. I'd prefer to keep it as is since it has some crypto deps.

decode-error/src/lib.rs

program/src/loader_v4.rs

t-nelson · 2025-05-02T14:25:51Z

Thanks for the review! To address your points:

solana_sdk::saturating_add_assign!() can be replaced by std::num::Saturating

Done, but it's gonna be loud in agave (145 uses)

luckily i believe a majority of usage is for metrics accumulations

solana_sdk::program_utils::limited_deserialize needs to go, but i haven't investigated why we changed the interface. i vaguely remember questioning why it exists at all

I'll make the deprecation louder, it's totally unused in agave right now

i have diffs that would suggest otherwise

solana_sdk::rpc_port should never have existed

It's still used unfortunately, but I can add it to solana-rpc-client-api or just locally define them wherever they're used in agave.

is it used externally to agave? i'd move the whole crate back to monorepo if so. there we can eliminate it with configs and cli arg defaults as god intended

joncinque · 2025-05-02T15:31:05Z

luckily i believe a majority of usage is for metrics accumulations

Nice

i have diffs that would suggest otherwise

Ah never mind, there's one usage at https://github.com/anza-xyz/agave/blob/7b368f27f69174eba154655bebd7d1775dabd3d3/core/src/banking_stage/latest_unprocessed_votes.rs#L12, all of the others use the version in solana_bincode directly. Unless you mean removing the function totally.

is it used externally to agave? i'd move the whole crate back to monorepo if so. there we can eliminate it with configs and cli arg defaults as god intended

Yikes, it's very used: https://github.com/search?q=solana_sdk%3A%3Arpc_port&type=code we haven't factored it into a separate crate, but I could do that in a follow-up

t-nelson · 2025-05-02T16:55:35Z

Yikes, it's very used: https://github.com/search?q=solana_sdk%3A%3Arpc_port&type=code we haven't factored it into a separate crate, but I could do that in a follow-up

tbf, anyone who thought using this was a good idea deserves to be broken

febo · 2025-05-02T17:12:28Z

sdk/src/lib.rs

+    pub use solana_program::loader_v4_instruction::*;
+}
+#[deprecated(since = "2.2.0", note = "Use `solana-message` crate instead")]
+pub use solana_message as message;


We probably need to tweak this one – something like:

#[deprecated(since = "2.2.0", note = "Use `solana-message` crate instead")] pub mod message { pub use solana_message::*; }

This one is actually on purpose -- my thinking is that Transaction / Message / Keypair / Signer are the most used types in solana-sdk, and will be the most annoying to remove, and aren't a problem to keep, so we keep it for now.

febo

Looks good to me.

joncinque · 2025-05-06T10:19:51Z

@apfitzge @t-nelson would you like to take another look?

apfitzge

lgtm from tx-metadata side

t-nelson

good start!

* Deprecate re-exports more loudly There are many different crates and types that we would like to remove from the sdk, but they are still re-exported from solana-sdk and solana-program. The re-exports have a `#[deprecated(...)]` attribute, but they aren't flagged to downstream users. Make the re-export deprecations louder by creating a deprecated module and re-exporting from in there. These are the types affected * `DecodeError`: this trait isn't all that useful, and is set to be removed entirely with anza-xyz#104, so deprecate it here These are the crates to no longer re-export from solana-program because they will be moved to program-specific repos: * `address_lookup_table` -> `solana_address_lookup_table_interface` * `bpf_loader_upgradeable` -> `solana_loader_v3_interface` * `loader_upgradeable_instruction` -> `solana_loader_v3_interface::instruction` * `loader_v4` -> `solana_loader_v4_interface` * `loader_v4_instruction` -> `solana_loader_v4_interface::instruction` * `nonce` -> `solana_nonce` * `feature` -> `solana_feature_gate_interface` * `loader_instruction` -> `solana_loader_v2_interface` * `vote` -> `solana_vote_interface` * `stake` -> `solana_stake_interface` * `stake_history` -> `solana_stake_interface::stake_history` * `system_instruction` -> `solana_system_interface` * `system_program` -> `solana_sdk_ids::system_program` (not sure about this one) Separately, `solana_message` and `solana_sanitize` are no longer re-exported. They never quite fit in `solana_program`, and caused more annoyance than anything else. The re-exports remain in `solana_sdk`. `solana-decode-error` will be removed entirely, so its deprecation is louder too. For `solana-sdk`, there are many types that just don't belong, so stop re-exporting these: * `commitment_config` -> `solana_commitment_config` * `genesis_config` -> `solana_genesis_config` * `hard_forks` -> `solana_hard_forks` * `rent_collector` -> `solana_rent_collector` * `alt_bn128` -> `solana_bn254` * `client` -> `solana_client_traits` * `compute_budget` -> `solana_compute_budget_interface` * `derivation_path` -> `solana_derivation_path` * `ed25519_instruction` -> `solana_ed25519_program` * `nonce_account` -> `solana_nonce_account` * `packet` -> `solana_packet` * `poh_config` -> `solana_poh_config` * `quic` -> `solana_quic_definitions` * `rent_debits` -> `solana_rent_debits` * `secp256k1_instruction` -> `solana_secp256k1_program` * `secp256k1_recover` -> `solana_secp256k1_recover` * `system_transaction` -> `solana_system_transaction` * `exit` -> `solana_validator_exit` * Address review feedback

joncinque requested a review from febo April 30, 2025 18:03

joncinque requested a review from a team as a code owner April 30, 2025 18:03

joncinque force-pushed the louddeprecate branch from 5972367 to 289b585 Compare April 30, 2025 18:06

t-nelson previously approved these changes Apr 30, 2025

View reviewed changes

apfitzge previously approved these changes May 1, 2025

View reviewed changes

Address review feedback

dc3f250

joncinque dismissed stale reviews from apfitzge and t-nelson via dc3f250 May 1, 2025 23:29

joncinque commented May 1, 2025

View reviewed changes

febo reviewed May 2, 2025

View reviewed changes

decode-error/src/lib.rs Show resolved Hide resolved

febo reviewed May 2, 2025

View reviewed changes

program/src/loader_v4.rs Show resolved Hide resolved

febo reviewed May 2, 2025

View reviewed changes

febo approved these changes May 5, 2025

View reviewed changes

apfitzge approved these changes May 6, 2025

View reviewed changes

t-nelson approved these changes May 6, 2025

View reviewed changes

joncinque merged commit 4dbfcc7 into anza-xyz:master May 6, 2025
24 checks passed

joncinque deleted the louddeprecate branch May 6, 2025 20:26

joncinque mentioned this pull request Jun 9, 2025

v3: Tracking issue for upcoming breaking changes #84

Closed

	#[deprecated(since = "2.3.0", note = "Use `solana-nonce` crate instead")]
	#[deprecated(since = "2.3.0", note = "Use `solana-system-interface::nonce` crate instead")]

Deprecate re-exports more loudly #151

Deprecate re-exports more loudly #151

Uh oh!

Conversation

joncinque commented Apr 30, 2025

Problem

Summary of changes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

t-nelson May 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

t-nelson commented Apr 30, 2025

Uh oh!

apfitzge left a comment

Choose a reason for hiding this comment

Uh oh!

joncinque left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

t-nelson commented May 2, 2025

Uh oh!

joncinque commented May 2, 2025

Uh oh!

t-nelson commented May 2, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

t-nelson May 2, 2025 •

edited

Loading