remove substrate compat (#1850)

* remove substrate compat

* add hacky example

* simplify substrate-compat example

* simplify substrate-compat example

* cargo fmt

* fix build

* add more examples

* fix nit

* fix test build

* Update subxt/examples/substrate_compat_signer.rs

Co-authored-by: James Wilson <james@jsdw.me>

* keep only polkadot signer example

* remove more substrate compat related stuff

* fix example

* link to substrate signer example in book

* Update subxt/src/book/usage/transactions.rs

* Update subxt/src/book/usage/transactions.rs

* address grumbles

* fix nits

---------

Co-authored-by: James Wilson <james@jsdw.me>

subxt/src/book/usage/transactions.rs

@@ -66,24 +66,23 @@
 //! There are two main ways to create a compatible signer instance:
 //! 1. The `subxt_signer` crate provides a WASM compatible implementation of [`crate::tx::Signer`]
 //! for chains which require sr25519 or ecdsa signatures (requires the `subxt` feature to be enabled).
-//! 2. Alternately, Subxt can use instances of Substrate's `sp_core::Pair` to sign things by wrapping
-//! them in a `crate::tx::PairSigner` (requires the `substrate-compat` feature to be enabled).
+//! 2. Alternately, implement your own [`crate::tx::Signer`] instance by wrapping it in a new type pattern.
 //!
 //! Going for 1 leads to fewer dependencies being imported and WASM compatibility out of the box via
 //! the `web` feature flag. Going for 2 is useful if you're already using the Substrate dependencies or
 //! need additional signing algorithms that `subxt_signer` doesn't support, and don't care about WASM
 //! compatibility.
 //!
-//! Let's see how to use each of these approaches:
+//! Because 2 is more complex and require more code, we'll focus on 1 here.
+//! For 2, see the example in `subxt/examples/substrate_compat_signer.rs` how
+//! you can integrate things like sp_core's signer in subxt.
+//!
+//! Let's go through how to create a signer using the `subxt_signer` crate:
 //!
 //! ```rust
-//! # #[cfg(feature = "substrate-compat")]
-//! # {
 //! use subxt::config::PolkadotConfig;
 //! use std::str::FromStr;
-//! use polkadot_sdk::{sp_core, sp_keyring};
 //!
-//! //// 1. Use a `subxt_signer` impl:
 //! use subxt_signer::{SecretUri, sr25519};
 //!
 //! // Get hold of a `Signer` for a test account:
@@ -94,34 +93,9 @@
 //!     .expect("valid URI");
 //! let keypair = sr25519::Keypair::from_uri(&uri)
 //!     .expect("valid keypair");
+//!```
 //!
-//! //// 2. Use the corresponding `sp_core::Pair` impl:
-//! use subxt::tx::PairSigner;
-//! use sp_core::Pair;
-//!
-//! // Get hold of a `Signer` for a test account:
-//! let alice = sp_keyring::AccountKeyring::Alice.pair();
-//! let alice = PairSigner::<PolkadotConfig,_>::new(alice);
-//!
-//! // Or generate a keypair, here from an SURI:
-//! let keypair = sp_core::sr25519::Pair::from_string("vessel ladder alter error federal sibling chat ability sun glass valve picture/0/1///Password", None)
-//!     .expect("valid URI");
-//! let keypair = PairSigner::<PolkadotConfig,_>::new(keypair);
-//! #
-//! # // Test that these all impl Signer trait while we're here:
-//! #
-//! # fn is_subxt_signer(_signer: impl subxt::tx::Signer<PolkadotConfig>) {}
-//! # is_subxt_signer(subxt_signer::sr25519::dev::alice());
-//! # is_subxt_signer(subxt_signer::ecdsa::dev::alice());
-//! # is_subxt_signer(PairSigner::<PolkadotConfig,_>::new(sp_keyring::AccountKeyring::Alice.pair()));
-//! # }
-//! ```
-//!
-//! See the `subxt_signer` crate or the `sp_core::Pair` docs for more ways to construct
-//! and work with key pairs.
-//!
-//! If this isn't suitable/available, you can either implement [`crate::tx::Signer`] yourself to use
-//! custom signing logic, or you can use some external signing logic, like so:
+//! After initializing the signer, let's also go through how to create a transaction and sign it:
 //!
 //! ```rust,no_run
 //! # #[tokio::main]

subxt/src/lib.rs

@@ -18,9 +18,6 @@
 ))]
 compile_error!("subxt: exactly one of the 'web' and 'native' features should be used.");
 
-#[cfg(all(feature = "web", feature = "substrate-compat"))]
-compile_error!("subxt: the 'substrate-compat' feature is not compatible with the 'web' feature.");
-
 // The guide is here.
 pub mod book;
 
@@ -115,10 +112,6 @@ pub mod ext {
     cfg_jsonrpsee! {
         pub use jsonrpsee;
     }
-
-    cfg_substrate_compat! {
-        pub use subxt_core::ext::{sp_runtime, sp_core};
-    }
 }
 
 /// Generate a strongly typed API for interacting with a Substrate runtime from its metadata.

subxt/src/macros.rs

@@ -12,12 +12,6 @@ macro_rules! cfg_feature {
 	}
 }
 
-macro_rules! cfg_substrate_compat {
-	($($item:item)*) => {
-		crate::macros::cfg_feature!("substrate-compat", $($item)*);
-	};
-}
-
 macro_rules! cfg_unstable_light_client {
 	($($item:item)*) => {
 		crate::macros::cfg_feature!("unstable-light-client", $($item)*);
@@ -64,8 +58,7 @@ macro_rules! cfg_reconnecting_rpc_client {
 }
 
 pub(crate) use {
-    cfg_feature, cfg_jsonrpsee, cfg_reconnecting_rpc_client, cfg_substrate_compat,
-    cfg_unstable_light_client,
+    cfg_feature, cfg_jsonrpsee, cfg_reconnecting_rpc_client, cfg_unstable_light_client,
 };
 
 // Only used by light-client.

subxt/src/tx/mod.rs

@@ -9,17 +9,9 @@
 //! additional and signed extra parameters are used when constructing an extrinsic, and is a part
 //! of the chain configuration (see [`crate::config::Config`]).
 
-use crate::macros::cfg_substrate_compat;
-
 mod tx_client;
 mod tx_progress;
 
-// The PairSigner impl currently relies on Substrate bits and pieces, so make it an optional
-// feature if we want to avoid needing sp_core and sp_runtime.
-cfg_substrate_compat! {
-    pub use subxt_core::tx::signer::PairSigner;
-}
-
 pub use subxt_core::tx::payload::{dynamic, DefaultPayload, DynamicPayload, Payload};
 pub use subxt_core::tx::signer::{self, Signer};
 pub use tx_client::{