program: Add deprecated note

[febo]

Problem

p-token was deployed to mainnet and the original SPL Token implementation won't be used going forwards.

Solution

Deprecate the spl-token crate and indicate that spl-token-interface should be used instead.

[joncinque]

Just some nits.

The comments stay vague with p-token by not naming the crate -- shall we commit to a crate name for p-token soon? 😁

[febo]

Just some nits.

The comments stay vague with p-token by not naming the crate -- shall we commit to a crate name for p-token soon? 😁

I was wondering if we could publish a minor version of spl-token-interface (after PR #153) and then "merge" spl-token-interface into pinocchio-token-interface. At that point, pinocchio-token-interface becomes the default one for both on-/off-chain.

Another alternative is to merge pinocchio-token-interface into spl-token-interface, so we keep the "spl-token" naming.

[joncinque]

Ah interesting, this is probably an important decision, since it'll determine how we adapt other interface crates, and potentially generated client crates.

From what I understand, we want to have a few "tiers" of program clients in Rust:

• generated types
• instruction creators
• off-chain types

In this case, spl-token-interface currently uses solana-instruction, which has allocations, and thus is more "off-chain". pinocchio-token-interface, on the other hand, is purely no-std, and has helpers more designed for on-chain usage.

Given that, it might make sense to keep them separated for now, but to have spl-token-interface re-export types from pinocchio-token-interface, which is more low-level.

But I can be convinced otherwise! We can also say that we don't really care for these crates since they're not generated clients. Or maybe I've misunderstood "off-chain" types, and those should actually contain even higher-level helpers.

cc @grod220@lorisleiva to weigh in

[febo]

In general, an "interface" crate has 3 clients:

1. program implementation: mostly use the instruction and error enums + state.
2. on-chain apps (programs): everything from 1) + CPI helpers.
3. off-chain apps: everything from 1) + instruction helpers.

So in practice we could have a single interface crate, which by default only brings things for 1), then a separate feature for each 2) and 3).

spl-token-interface
|
+- instruction.rs
+- error.rs
+- state/*
|
+- ["cpi" feature]
| └ CPI helpers (currently in pinocchio-token crate)
|
+- ["instruction" or "client" feature]
└ off-chain instruction helpers (currently on spl-token-interface crate)

[febo]

Forgot to add that 2) and 3) would ideally be generated from the information in 1).

[joncinque]

Sorry for the slowness, we can merge this in and decide how to merge the interface crates in a future PR / discussion

[lorisleiva]

Did we not decide on spl-token-client? 😬

[joncinque]

Did we not decide on spl-token-client? 😬

I think so -- I would keep the interface description in one place as *-interface, generate the IDL from that, and have everything else in spl-token-client, which can re-export the state / instruction / errors from the interface if we want