renderers-rust: extract pubkey from solana-program #535
Conversation
|
|
@lorisleiva @febo I'm mostly looking to open this up for discussion, but I think this can actually land as-is. We might be able to incrementally extract child crates like so going forward, if this is the direction we want to take. I think the version bump is the only major issue. Regardless, what do you think about going in this direction for Codama? I feel like it's something that was bound to happen anyway, since most people are moving away from Also, worst case, developers can always adjust their client library's manifest themselves, so if they need more child crates, or if they want to use the kitchen sinks for some reason, they can do so. We don't necessarily have to make libraries like IMO, Codama should generate clients with the lightest crates possible, and let developers build on those, either through renderer configurations or additional developer-added code. What do you guys think? |
|
Hey Joe, sorry for the late reply, I meant to answer later and completely forgot to got back to it. I think this makes sense. I'd love to have @febo's input on this though since I think there's gonna be some slight changes in the core crates that provide types such as |
|
@buffalojoec Let's get all individual crates integrated and remove |
|
@lorisleiva @febo thanks guys! I think the whole effort is a bit of a bear, but maybe we can do it over time? If at any time a patch needs to go out for some other reason, having just Sounds like I should merge this then? |
|
@buffalojoec Actually, could we just wait on this until I decouple the renderer's versioning with the rest of Codama? One annoying side effect of bundling renderers with the CLI and then including that CLI in the main I'm planning on fixing this by not including the Codama CLI in the main But also since this is a Rust renderer breaking change, it would be a net benefit to do all the crate changes in one big breaking change upgrade, right? |
|
@lorisleiva OK, no worries. I'm not blocked on this for anything, and I agree I think it makes sense to do it all in one swing anyway. Since the changes should be all within the manifests and imports sections, we might be able to make a branch and just continue to add support for different "mini" crates until eventually we can evict The idea would be to occasionally rebase it on top of Wdyt? |
|
@buffalojoec Yeah I think having a feature branch for this makes sense. We also have Graphite for Codama (free as their open source license) so we could also do a big ol' PR stack with Graphite and merge the lot when we're ready. Up to you though, I'm happy with either strategies. |
|
@lorisleiva tbh I don't have Graphite setup anymore, so how about we go with the branch for now, and when we are looking ready to prepare a merge we can decide if we want to make each commit a Graphite branch? I've just been working with my commits as if they were Graphite branches anyway. If you're down, you could cut a new branch off the current head and change the base here, then we can merge it! |
lorisleiva
changed the base branch from
main
to
renderers-rust/use-granular-crates
|
Sounds good! 👌 |
lorisleiva
merged commit ae3ca97
into
codama-idl:renderers-rust/use-granular-crates
3 participants
This is just an experimental PR to open up discussion.
Both the Solana SDK and the Solana-Program SDK have been broken up into many tiny crates, and switching over to these in any Rust project drastically improves compile time. Furthermore, building client libraries without the kitchen sink
solana-programorsolana-sdkdependencies won't bog down compile times for any other libraries or applications built on top of them.This PR is potentially the first in very many to bust up the Solana SDKs in Codama's generated Rust clients.