#soroban rust create [project-name]
28 messages · Page 1 of 1 (latest)
Would be useful, but I don't think its place is in the Soroban CLI. Perhaps an add-on (plugin) to cargo would be better? Also, adding this to the CLI would also mean maintaining it alongside the cli's own features which don't really correlate to building a project but rather using soroban.
There's also a consideration related to other ways of creating projects, such as sdk-js, sdk-assemblyscript, etc.
in the future if people actually make these sdk's, in addition to the 'native Rust' one
what do you think @modest hornet @pulsar birch @lethal star @rapid stratus ?
@lavish hedge ?
Also... by "project" do you mean only the smart contract (aka backend)? For the near future, I do see the need for templating to make complete projects based on your preferred tech stack. (Rust SC+Yew UI | Rust SC+Leptos | Rust SC + React FE, etc.)
that last idea would sure help drive adoption, lowering the barrier to make projects while at the same time promoting best practices for each of those tech stacks
But I might be overshooting this 🙂 it WILL BE complex to say the least
I'm not quite sure what we'd understand to be 'a project with the basics' set up. But I've been using gitpod to this effect, it spins up an environment with Rust, Soroban-sdk and cli
@cosmic yarrow care to elaborate on what you consider "basics"?
Ohh yeah sorry I should've added a bit more information. I just thought about it when I was going through the https://soroban.stellar.org/docs/getting-started/hello-world page setting up a rust contract project. I just thought it might be useful if there is a soroban rust create [project-name] command to setup the whole rust project and add all the information below for us already:
cargo.toml
[lib]
crate-type = ["cdylib"]
[dependencies]
soroban-sdk = "0.6.0"
[dev_dependencies]
soroban-sdk = { version = "0.6.0", features = ["testutils"] }
[features]
testutils = ["soroban-sdk/testutils"]
[profile.release]
opt-level = "z"
overflow-checks = true
debug = 0
strip = "symbols"
debug-assertions = false
panic = "abort"
codegen-units = 1
lto = true
[profile.release-with-logs]
inherits = "release"
debug-assertions = true
lib/lib.rs
#![no_std]
use soroban_sdk::{contractimpl, symbol, vec, Env, Symbol, Vec};
pub struct Contract;
#[contractimpl]
impl Contract {
pub fn hello(env: Env, to: Symbol) -> Vec<Symbol> {
// Your implementation
}
}
lib/test.rs
#![cfg(test)]
use super::{Contract, ContractClient};
use soroban_sdk::{symbol, vec, Env};
#[test]
fn test() {
let env = Env::default();
let contract_id = env.register_contract(None, Contract);
let client = ContractClient::new(&env, &contract_id);
}
I see you're approaching this from Flutters background haha
You got me! 😛
Honestly I'd like that. It would also be great to add other examples such as Soroban auth
Yeah just the basic stuff that most people need for almost all of their contracts right.
Maybe they can by default just add the code for soroban quest 2. It has auth and storage. Its a really good starting point for many I guess.
i think a cargo plugin would be nice for this
i like the idea
it could save me a precious few minutes each time i create a new project
i'm not sure if it should be soroban-cli or a cargo package but i do like the idea of having a fast way to copy a template
it could save you a lot more if the plugin has the capacity to actually scaffold an entire project based on your preference of tech stack 🙂
think...
cargo new-soroban-solution --components=auth,classic-token-support --front-end=react --backend-sdk-lang=rust
it could even go further and ask for basic config via interactive-clap prompts
that's interesting sort of like the way npx works with create-react-app
I like the concept! Anything to make it easier for dev to get started with soroban
Good to hear you guys like this as well 🙂
We've been throwing around an idea for soroban-cli plugins, or more non-core stuff. Currently stuff under soroban lab .... Maybe this would be a good fit under there.
I personally lean more towards this being a separate thing from soroban-cli, maybe a repo template you fork, or separate project like create-react-app. 🤔
I'm not sure this quite fits - cli is more or less SDK agnostic (as long as some expected metadata is provided), so creating a project for a specific SDK (even the most used one) seems off to me. nothing wrong about having such tools in general, but I'm not sure everything should belong to a single binary
Agree, I don't think its place is the cli... what do you think of the idea of a cargo plugin for this? @thin yacht