Make spl-program-ids crate and move declare_id usage in there

[kevinheavey]

There are many cases of people adding, for example, spl_token_2022 as a dependency just so they can import the program ID. This is terrible for dependency bloat and conflicts.

This PR puts SPL program IDs in one crate and re-exports them in their original crates for backwards compatibility.

On my machine a release build of the new spl_program_ids crate takes 0.05s after compiling its dependencies, so I definitely think it's fine to dump every SPL program ID in here. Semver also shouldn't get messy since it's not like we expect breaking changes to the IDs

[joncinque]

Thanks for the contribution! We're working on breaking up the SPL repo into many component repos and creating lightweight client crates, like in https://github.com/solana-program/token, so I want to avoid bundling a bunch of program info in one crate at this stage. And I definitely want to avoid programs that we never really supported or deployed to mainnet, like record and binary option.

[kevinheavey]

We're working on breaking up the SPL repo into many component repos and creating lightweight client crates

That's orthogonal to the problem of people importing SPL crates just to get the program ID though

[joncinque]

Not entirely, rather than having a kitchen sink of program ids, people should use the client crates for the programs they care about. If they want a kitchen sink, they can make their own, but we should move towards splitting programs up rather than bundling them together, especially when a lot of them don't make sense together.

Do you think program clients should have a separate crate which just contains the program id?

[kevinheavey]

Do you think program clients should have a separate crate which just contains the program id?

This would be excessive even for me. It'd be more work to add the crate than just copy-paste the program ID. But copy-pasting program IDs is not great at the same time. How would you suggest proceeding in #7005 ?

The problems with kitchen sink crates are:

• Dependency conflicts
• Build times
• Bigger surface area for semver

None of these are an issue with a crate that has a dozen or so Pubkey constants that are not changing or growing quickly.

[joncinque]

That's a good point -- maybe instead of "just a program id" crate, we really want an "all the addresses" crate?

[kevinheavey]

"all the addresses" crate

What would go in there?

[joncinque]

Oh sorry, I was thinking it would be all static IDs and functions to generate PDAs

[kevinheavey]

What are the programs that should be left out? You mentioned record and binary-option

[joncinque]

I meant each program would have an addresses crate containing its program id and PDA derivations.

But in the meantime, maybe what's really needed is something like https://github.com/anza-xyz/agave/tree/master/inline-spl that also contains the ATA derivation function. Would that solve your issue?

[kevinheavey]

The inline-spl crate will be close enough (still annoying to have a bytemuck dep) when this is merged anza-xyz/agave#2186