Code Monkey home page Code Monkey logo

shuttle's Introduction


language docs crate-docs status build status

crates discord Twitter Follow

open bounties rewarded bounties


Fastest Way to Build & Ship Rust Apps

Get resources and deploy your apps with a few lines of code.

Simple.   Easy.   Joyful.

Report Bug · Request a Feature · Join Our Discord · Follow us on Twitter


⭐ If you find Shuttle interesting, consider starring this repo to help spread the word.

Features

  • One-line Resource Provisioning: Get a database, or any other AWS resource by adding a line of code to your main file. To delete one, just remove that line of code. No config/yaml files required.
  • Rapid Development: It takes 2 minutes from project initialization to a deployed project. It takes another 2 minutes to provision a resource, and get it deployed to production.
  • First-class support for popular Rust frameworks: Axum, Actix Web, Rocket, and more
  • Security: Let us worry about the security & permissions while you focus on writing good code.


Quick Start

On Linux and macOS, you can use this install script, which will automatically install the correct target for your OS and distro:

curl -sSfL https://www.shuttle.rs/install | bash

On Windows, you can use this install script to do the same:

iwr "https://www.shuttle.rs/install-win" | iex

After installing, log in with:

cargo shuttle login

To initialize your project, simply write:

cargo shuttle init --template axum hello-world

And to deploy it, write:

cd hello-world
cargo shuttle project start  # Only needed if project has not already been created during init
cargo shuttle deploy --allow-dirty

And... that's it!

Service Name:  hello-world
Deployment ID: 3d08ac34-ad63-41c1-836b-99afdc90af9f
Status:        running
Last Updated:  2022-04-01T08:32:34Z
URI:           https://hello-world.shuttleapp.rs

Feel free to build on top of the generated hello-world boilerplate or take a stab at one of our examples.

For the full documentation, visit our docs.

Quick Look

Below is a basic "Hello World" application written in Axum:

use axum::{routing::get, Router};

#[tokio::main]
async fn main() {
    let app = Router::new().route("/", get(hello_world));

    let listener = tokio::net::TcpListener::bind("127.0.0.1:3000")
        .await
        .unwrap();
    println!("listening on {}", listener.local_addr().unwrap());
    axum::serve(listener, app).await.unwrap();
}

async fn hello_world() -> &'static str {
    "Hello, world!"
}

In order to be able to deploy it with a single command, we update the snippet as follows:

use axum::{routing::get, Router};

async fn hello_world() -> &'static str {
    "Hello, world!"
}

#[shuttle_runtime::main]
async fn main() -> shuttle_axum::ShuttleAxum {
    let router = Router::new().route("/", get(hello_world));

    Ok(router.into())
}

Now, with just cargo shuttle deploy, you can see your application live. But let's enhance it further by adding a shared Postgres database:

use axum::{routing::get, Router};

async fn hello_world() -> &'static str {
    "Hello, world!"
}

#[shuttle_runtime::main]
async fn main(
    #[shuttle_shared_db::Postgres] pool: sqlx::PgPool,
) -> shuttle_axum::ShuttleAxum {

    pool.execute(include_str!("../schema.sql"))
        .await
        .expect("failed to run migrations");

    let router = Router::new().route("/", get(hello_world));

    Ok(router.into())
}

Now, if we run cargo shuttle deploy, we'll have an up and running project with a database inside & ready to use.

Repositories

Name Description
shuttle 🚀 (This repo) The core Shuttle product. Contains all crates that users interact with.
shuttle-examples 👨‍🏫 Officially maintained examples of projects that can be deployed on Shuttle. Also has a list of community examples.
shuttle-docs 📃 Documentation hosted on docs.shuttle.rs.
www 🌍 Our website shuttle.rs, including the blog and Launchpad newsletter.
deploy-action GitHub Action for continuous deployments.
awesome-shuttle 🌟 An awesome list of Shuttle-hosted projects and resources that users can add to.
shuttlings ⚔️ A collection of Rust code challenges. A great way to get started with using Rust and Shuttle.


Contributing to Shuttle

Contributing to Shuttle is highly encouraged! Even if you are not planning to submit any code, joining our Discord server and providing feedback helps us a lot!

Check out our contributing docs and find the appropriate repo above to contribute to. For development of this repo, check the development docs.

Algora Bounties 💰

To offload work from the engineering team on low-priority issues, we will sometimes add a cash bounty to issues. Sign up to the Algora Console to find open issues with bounties.

Project Status

Check for any outages and incidents on Shuttle Status.

We are currently in Public Beta. Watch "releases" of this repo to get notified of major updates! Also, check out the Beta announcement for features we are looking forward to.

  • Alpha: We are testing Shuttle, API and deployments may be unstable
  • Public Alpha: Anyone can sign up, but go easy on us, there are a few kinks
  • Public Beta: Stable enough for most non-enterprise use-cases
  • Public: Production-ready!


Contributors ✨

Thanks goes to these wonderful people:

Made with contrib.rocks.

shuttle's People

Contributors

akrantz01 avatar alphakeks avatar beyarkay avatar bmoxb avatar brokad avatar chesedo avatar christos-h avatar coszio avatar fatfingers23 avatar gautamprikshit1 avatar gugagongadze avatar iamwacko avatar iulianbarbu avatar ivancernja avatar jmwill86 avatar jonaro00 avatar joshua-mo-143 avatar kaleidawave avatar kazy avatar kierendavies avatar marioidival avatar nahuakang avatar oddgrd avatar orhun avatar paulotten avatar sentinel1909 avatar supleed2 avatar thass0 avatar thecotne avatar xavientois avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

shuttle's Issues

feature: support multiple back-ends

The shuttle api currently works exclusively with AWS. All the infrastructure definition is in terraform and explicit AWS modules are used.

For portability purposes it would be nice to have multiple back-ends supported:

  • Azure
  • GCP

failing cargo shuttle deploy returns successful exit code

if I forget to do the lib.crate-type = ["cdylib"] dance, cargo shuttle deploy gives me:

   Compiling reqwest v0.11.9
   Compiling dancelist v0.1.0 (/opt/unveil/crates/dancelist)
    Finished dev [unoptimized + debuginfo] target(s) in 1m 37s

        Project:            dancelist
        Deployment Id:      d3a0e264-f785-42d5-bf85-0d39aba5fb36
        Deployment Status:  ERROR: "a cdylib was not created"
        Host:               dancelist.shuttleapp.rs
        Created At:         2022-04-15 06:38:17.692974962 UTC

but cargo-shuttle's exit code is still "success" ($? == 0) in this case :-( . This means that bash's && and || chains do the wrong thing. This also means you can't build useful CI pipelines, etc.

Originally posted by @alsuren in qwandor/dancelist#2 (comment)

sqlx version mismatch error

When I try to call cargo shuttle run with the example postgres code from the docs, I get the following error:

error[E0308]: mismatched types
  --> src/lib.rs:16:17
   |
16 | async fn rocket(pool: PgPool) -> ShuttleRocket {
   |                 ^^^^ expected struct `Pool`, found struct `sqlx_core::pool::Pool`
   |
   = note: expected struct `Pool<Postgres>`
              found struct `sqlx_core::pool::Pool<sqlx_core::postgres::database::Postgres>`
   = note: perhaps two different versions of crate `sqlx_core` are being used?

My dependencies are:

shuttle-service = { version = "0.3.3", features = ["web-rocket", "sqlx-postgres"] }
sqlx = { version = "0.6", features = ["runtime-tokio-native-tls", "postgres"] }

Changing the sqlx version to 0.5 fixes the error, but I wonder what the best approach for avoiding this kind of version mismatch would be.

Document self-deployments

The entire platform, client and server code, is open-source and its code is in this repo. However, self-deployment is not documented anywhere so it makes it hard for someone to implement self-deployments by themselves without requiring help from Discord.

What we can do

Document, as a "getting started" step in the shuttle-service crate and in the README.md here, that self-deployment is an option and point to a small guide (probably another .md file in the root of the repo or a wiki page) which explains how to self-deploy.

cargo shuttle ignores Shuttle.toml if run in subdir of crate

The logic to find Cargo.toml works fine, but we don't then use the location of Cargo.toml to search for a Shuttle.toml (and will continue as if it's not there). This means that it will have the wrong project name.

I wrote a test for this in #122 to help when implementing this. See #122 (comment)_

It's very much an edge case, so might not be worth fixing.

feature: cargo shuttle init

Introduce an init function to cargo-shuttle that will initialise the barebones of a project (similar to cargo init). cargo shuttle init <name>

This should probably:

  1. Add an Init(ProjectName) variant to Command in args.rs
  2. Call cargo init --lib via the cargo crate
  3. Automatically add the crate-type = ["cdylib"] to cargo.toml
  4. Add the shuttle-service deps top cargo.toml.

Bonus points - have a separate cargo init command for each framework supported. For example with Rocket:

  1. cargo shuttle init-rocket <name>
  2. As above, but also add the feature flags: shuttle-service = { version = "0.2", features = ["web-rocket"] }
  3. Also create hello-world scaffolding
#[macro_use]
extern crate rocket;

use rocket::{Build, Rocket};

#[get("/")]
fn index() -> &'static str {
    "Hello, world!"
}

#[shuttle_service::main]
async fn rocket() -> Result<Rocket<Build>, shuttle_service::Error> {
    Ok(rocket::build().mount("/hello", routes![index]))
}

Compose.dev.yml uses sometimes-deprecated `extends` feature

Shuttle's dev.yml attempts to extend the base backend, but the backend depends_on the provisioner service. It seems some versions of Compose no longer allow to extends a service that contains a depends_on, particularly ones post-3 but prior to the current version.

See the note in Compose's docs: https://docs.docker.com/compose/extends/#extending-services

The version of Compose the install guide led me to was one of these. I was eventually able to solve it by manually installing a fresh Compose binary as a CLI Plugin, but it took a while to figure out the issue. I'd imagine I won't be the last person to encounter this. Would everyone be open to adding a note to the Contributing/setup instructions mentioning it?

Windows deploy broken due to Cargo bug

Windows currently fails to deploy. The bug is related to this Cargo meta-issue. Cargo is still trying to determine how to fix them properly in general.

I forked Cargo, fixed our instance of the bug by canonicalizing the malformed path, and patched Shuttle with it here which I've tested working on Windows/WSL(Ubuntu) and the normal CI tests. The change may be small and innocuous enough that the Cargo folks would accept a PR?

feature: feature-gate OpenSSL dependency

sqlx has a dependency on native-tls. Not every environment has OpenSSL and whatever the Win equivalent is. rustls is more interoperable.

    │   │   ├── sqlx-rt v0.5.11
    │   │   │   ├── native-tls v0.2.8
    │   │   │   │   ├── log v0.4.14 (*)
    │   │   │   │   ├── openssl v0.10.38
    │   │   │   │   │   ├── bitflags v1.3.2
    │   │   │   │   │   ├── cfg-if v1.0.0
    │   │   │   │   │   ├── foreign-types v0.3.2
    │   │   │   │   │   │   └── foreign-types-shared v0.1.1
    │   │   │   │   │   ├── libc v0.2.120
    │   │   │   │   │   ├── once_cell v1.10.0
    │   │   │   │   │   └── openssl-sys v0.9.72
    │   │   │   │   │       └── libc v0.2.120
    │   │   │   │   │       [build-dependencies]
    │   │   │   │   │       ├── autocfg v1.1.0
    │   │   │   │   │       ├── cc v1.0.73
    │   │   │   │   │       └── pkg-config v0.3.24
    │   │   │   │   ├── openssl-probe v0.1.5
    │   │   │   │   └── openssl-sys v0.9.72 (*)
    │   │   │   ├── once_cell v1.10.0
    │   │   │   ├── tokio v1.17.0 (*)
    │   │   │   └── tokio-native-tls v0.3.0
    │   │   │       ├── native-tls v0.2.8 (*)
    │   │   │       └── tokio v1.17.0 (*)

https://github.com/getsynth/shuttle/blob/main/api/Cargo.toml#L19 explicitly states

sqlx = { version = "0.5", features = ["runtime-tokio-native-tls", "postgres"] }

which may be for a good reason.

Consider using runtime-tokio-rustls instead

Support axum

axum is a great modular web framework which has many benefits over other frameworks. And even though anybody can deploy an axum service by implementing IntoService in custom code, it would be a nicer experience to have first-class support (like we do for Rocket).

Is shuttle tied to Rocket, or are other servers possible?

The initial paragarph doesn't mention Rocket, but all the examples use it, and it is not clear if we can use another server architecture.
Even if it is not yet supported, but is intended to be supported, it would be good to hear about it.

Write a README for `cargo-shuttle`

In the [Deploying](https://docs.rs/shuttle-service/latest/shuttle_service/#deploying) section there is a link to cargo shuttle
which links to https://docs.rs/crate/cargo-shuttle/latest.

That leads to a valid page, but its main content is cargo-shuttle-0.2.2 is not a library. which is not particularly welcoming.

Allow examples to run locally

When trying to run the Rocket Postgres and URL Shortener examples locally, they fail due to a compilation error:

error[E0433]: failed to resolve: use of undeclared crate or module `shared`
  --> src/lib.rs:52:19
   |
52 | async fn rocket(#[shared::Postgres] pool: PgPool) -> shuttle_service::ShuttleRocket {
   |                   ^^^^^^ use of undeclared crate or module `shared`

I tried to fix it with this PR #249, but when the CI ran, it gave me the following error here:

error: resource needs an attribute configuration
  
 = help: Try adding a config like `#[shared::Postgres]`
  
 --> src/lib.rs:52:17
   |
52 | async fn rocket(pool: PgPool) -> shuttle_service::ShuttleRocket {
   |                 ^^^^

I have struggled to find documentation on this error and this annotation, so it has been difficult to try to make a fix for this.

Link to released example code in website

On the website, instead of linking to the example code on main:

It might make sense to link to the example code for the latest released version of cargo-shuttle rather than main, to avoid similar confusion for first-time users in the future.

Originally posted by @Xavientois in #250 (comment)

Object persistence from annotations

Currently the only form of persistence across runs of a service is an (optional) database accessible via Factory.

Maybe we could allow users to "persist" a serializable/deserializable object across runs with a simple derive annotation

#[derive(Serialize, Deserialize, Persist)]
struct MyPersistingState {
  view_counter: usize
}

docs: communicate the shuttle build process

At the moment there seems to be a lot of magic in the process.
Magic is good, but it can be disconcerting for large/serious users.
IMO it is important to understand a bit about what shuttle is doing with your code.
Of course, this could be found out by digging through the code, but it's probably
better to have this available up-front.

I'd like to see answers to questions like:

Is the code being compiled locally and then compiled version copied to the shuttle.rs servers?
Or is the code being shipped there and then compiled?

If the latter, what security is in place for ensuring
private code is not made publicly available? (Is each compile happening in a chroot jail, as a unique user, or something else?)
How do you handle private or local cargo entries?

If the former, how is the compilation happening? For example, I'm on an old mac, which won't cross-compile to Linux
without a lot of work (and a lot of extra tools I don't have disk space for...)

feature: support path dependencies

cargo-shuttle uses cargo package under the hood to package project files into a tarball and ship them to the shuttle api for them to be built.

A limitation of cargo package is that it will refuse to package path dependencies.

Implementation of this is unclear - some design is required as with the current build system changes to the underlying file-system will probably be required.

E2E tests fail due to container being marked for removal

For some of my PRs the CI will run successfully until the E2E test step, where it will fail with the following error:

Error response from daemon: container is marked for removal and cannot be started
make: *** [Makefile:46: up] Error 1
CONTAINER_REGISTRY=public.ecr.aws/q0k3o0d8 docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d

example

I do not know what causes this error, but it makes opening PRs a bit more difficult of a process.

Add rustfmt.toml

My VSCode kept re-formatting the code on Ctrl+Shift+I creating huge diffs. All contributors should share the same formatting rules.

See https://rust-lang.github.io/rustfmt/

The alternative is to accept that the diffs will contain formatting changes potentially reverting back and forth depending on who's got what version of rustfmt installed.

Use a `tokio::main` style proc-macro instead of `declare_service`

If I want to deploy a service, I need to use declare_service!. An example usage is:

struct MyState(PgPool);

async fn state(
   factory: &mut dyn Factory
) -> Result<MyState, shuttle_service::Error> {
   let pool = sqlx::postgres::PgPoolOptions::new()
       .connect(&factory.get_sql_connection_string().await?)
       .await?;
   Ok(MyState(pool))
}

fn rocket() -> Rocket<Build> {
    rocket::build()
}

declare_service!(Rocket<Build>, rocket, state);

It would be clearer and reduce redundancy if, instead, it looked like this:

#[shuttle_service::main]
fn main() -> impl IntoService {
   rocket::build().mount("/", routes![hello])
}

// If database is required:
#[shuttle_service::main]
fn main(stuff: SqlxDatabase) -> impl IntoService {
   let stuff_string = stuff.get_connection_string();
   // TODO: Code to share database with routes.
   rocket::build().mount("/", routes![hello])
}

// If databases are required:
#[shuttle_service::main]
fn main(users: SqlxDatabase, sessions: RedisCache) -> impl IntoService {
   let users_string = users.get_connection_string();
   let sessions_string = sessions.get_connection_string();
   // TODO: Code to share database with routes.
   rocket::build().mount("/", routes![hello])
}

(thanks @finnbear for the idea and the example snippet above!)

docker-buildx / docker-compose builds failing

The new changes for local deployments and local setup are failing for me with some missing ENV variables and provisioner connection problems it seems?

docker compose -f docker-compose.dev.yml up --build output:

shuttle-jw-db-1           | 2022-06-30 22:58:08.898 UTC [1] LOG:  database system is ready to accept connections
shuttle-jw-backend-1      | thread 'main' panicked at 'failed to connect to provisioner: tonic::transport::Error(Transport, hyper::Error(Connect, ConnectError("tcp connect error", Os { code: 111, kind: ConnectionRefused, message: "Connection refused" })))', api/src/deployment.rs:380:14
shuttle-jw-backend-1      | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
shuttle-jw-backend-1 exited with code 101
shuttle-jw-provisioner-1  | Error: Format string '/usr/bin/wait-for-pg-then /usr/local/bin/shuttle-provisioner --ip 0.0.0.0 --port %(ENV_PORT)s --shared-pg-uri %(ENV_PG_URI)s' for 'program:shuttle-provisioner.command' contains names ('ENV_PORT') which cannot be expanded. Available names: ENV_CARGO_HOME, ENV_HOME, ENV_HOSTNAME, ENV_PATH, ENV_PG_CLUSTER_NAME, ENV_PG_DATA, ENV_PG_HOST, ENV_PG_LOG, ENV_PG_PASSWORD, ENV_PG_PORT, ENV_PG_URI, ENV_PG_VERSION, ENV_PWD, ENV_RUSTUP_HOME, ENV_RUST_LOG, ENV_RUST_VERSION, ENV_SHLVL, group_name, here, host_node_name, process_num, program_name in section 'program:shuttle-provisioner' (file: '/usr/share/supervisord/supervisord.conf')
shuttle-jw-provisioner-1  | For help, use /usr/bin/supervisord -h
shuttle-jw-provisioner-1 exited with code 2
shuttle-jw-backend-1      | thread 'main' panicked at 'failed to connect to provisioner: tonic::transport::Error(Transport, hyper::Error(Connect, ConnectError("dns error", Custom { kind: Uncategorized, error: "failed to lookup address information: Name or service not known" })))', api/src/deployment.rs:380:14
shuttle-jw-backend-1      | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
shuttle-jw-backend-1 exited with code 101
shuttle-jw-backend-1      | thread 'main' panicked at 'failed to connect to provisioner: tonic::transport::Error(Transport, hyper::Error(Connect, ConnectError("dns error", Custom { kind: Uncategorized, error: "failed to lookup address information: Name or service not known" })))', api/src/deployment.rs:380:14
shuttle-jw-backend-1      | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
shuttle-jw-backend-1 exited with code 101
shuttle-jw-backend-1      | thread 'main' panicked at 'failed to connect to provisioner: tonic::transport::Error(Transport, hyper::Error(Connect, ConnectError("dns error", Custom { kind: Uncategorized, error: "failed to lookup address information: Name or service not known" })))', api/src/deployment.rs:380:14
shuttle-jw-backend-1      | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
shuttle-jw-backend-1 exited with code 101

There's also a 'No such file or directory' error on build, changing /usr/local/bin/service to /usr/local/bin/shuttle-backend in the dev docker-compose.yml seem to fix this though.

feature: test / staging environments

Shuttle only has a production environment right now. Obviously as your developing features you may want to deploy to a temporary testing environment to try out your changes before pushing to production.

This is quite a big one - requires quite a bit of design and changes to infrastructure.

It's not clear from the main page if "open-source" applied to client only, or server code too.

The main docs contain

Shuttle is an open-source app platform that uses traits and annotations to configure your backend deployments.

It's not clear to me if this is tied to publishing on shuttle.rs or if the server code is available.
i.e. is shuttle.rs just providing hosting and is the default location, or is there a vendor lock-in too.
(Admittedly it looks like this is primarily a wrapper for deploying and managing rocket applications,
so migrating away if necessary shouldn't be tricky).

feature: run shuttle on Kubernetes

Shuttle currently runs on AWS via terraform config.

Deploying on Kubernetes would offer non-cloud, cross-cloud and alternative cloud provider support.

feature: tailing logs

cargo-shuttle has logging functionality with cargo shuttle logs - but this prints the entire log history of a deployment and terminates.

This feature proposes log tailing, where the user can have access to a constant stream (follow basically) of logs from cargo-shuttle using cargo shuttle logs --tail or cargo shuttle logs -t.

Secrets

There is no way currently to deploy a service which requires a secret or other private deployment variables (like a third-party API key or custom private keys), short of embedding it in the compiled code with something like a static.

It'd be nice to have the ability to add deployment variables to Shuttle.toml (or a Secrets.toml for private stuff?) which will then be provided at runtime to the service through Factory.

feature: run tests before deploy

When you run a cargo shuttle deploy the cargo workspace is cargo package'd and shipped to shuttle's API servers where it's compiled and then deployed.

Ideally we would want a pre-deploy step which runs cargo test before the service is deployed (we probably also want a flag to skip this like cargo shuttle deploy --no-test).

Open question if we want the tests to run by default or not.

feature: `cargo shuttle logs`

Currently logs are stored on the server without a user having access to them.

This feature proposes a cargo shuttle logs command similar to heroku logs and heroku logs -t for tailing.

Customizable Host headers

Currently the deployment router at the edge will use the value of the Host: header to decide where to route requests and by default will only accept my-project-name.shuttleapp.rs. This is not ideal for self-deployments which are not deployed as a subdomain of shuttleapp.rs.

We could expose a parameter in Shuttle.toml which lets users configure a Host key for their deployment.

bug: running `cargo shuttle status` outside a cargo project panics

The error message looks like this:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: CargoMetadata { stderr: "error: could not find `Cargo.toml` in `/path/to/folder` or any parent directory\n" }', /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-shuttle-0.2.5/src/config.rs:224:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The desired behavior (for any sub-command which relies on being in a cargo project) should notify the user that they are not currently in the context of a cargo project:

error: could not find `Cargo.toml` in `/path/to/some/dir` or any parent directory

I haven't played around with it yet - but replacing unwrap with ? could do the trick :)

"a cdylib was not created"

Following the Getting Started section in your readme (commit 036f2ac) I get the following output when I run cargo shuttle deploy:

    Finished dev [unoptimized + debuginfo] target(s) in 1m 15s

        Project:            jacob-test-rocket
        Deployment Id:      d14baaef-aaac-42d3-a0d1-cc4ec23e8ccb
        Deployment Status:  ERROR: "a cdylib was not created. Try adding the following to the Cargo.toml of the service:\n[lib]\ncrate-type = [\"cdylib\"]\n"
        Host:               https://jacob-test-rocket.shuttleapp.rs
        Created At:         2022-07-04 06:33:34.139652374 UTC

I tried using the cargo-shuttle version from main (commit 036f2ac) but that gives the same error message as above.

Use clap v3 for command line argument parsing

Currently, clap v3 is used in the provisioner crate:

clap = { version = "3.1.18", features = ["derive", "env"] }
while structopt is used in api and cargo-shuttle:
structopt = "0.3.26"
structopt = "0.3.26"

Now that all of structopt's features are in clap v3 and structopt is in maintenance mode, it might make sense to migrate all crates in the workspace to use clap v3 to allow access to new features and a uniform way to define CLIs across Shuttle crates.

For this and other CLI dependencies, it might make sense to add them as workspace dependencies to allow all crates in the workspace to reference the shared version.

feature: support custom domain

Currently shuttle apps are automatically provisioned a subdomain, for example 'my-app.shuttleapp.rs'. This feature adds the ability to support user-owned domains, 'my-app.com'.

Support import of own crate in main.rs

Thank you for releasing 0.4 which no longer requires crate-type = ["cdylib"], this is great!

Another thing I would like to see is the ability to import the own crate in main.rs, but it seems that one can no longer use cargo shuttle run or cargo shuttle deploy after doing that.

MRE / Minimal reproducible example:

cargo install [email protected]
git clone [email protected]:shuttle-hq/shuttle.git
cd shuttle/examples/axum/hello-world
echo 'pub fn say_hi() { println!("hi"); }' >> src/lib.rs
echo 'use hello_world::say_hi; fn main() { say_hi(); }' > src/main.rs
cargo shuttle run

The last command gives the following output for me:

    Building /Users/jacob/Downloads/shuttle/examples/axum/hello-world
   Compiling hello-world v0.1.0 (/Users/jacob/Downloads/shuttle/examples/axum/hello-world)
error[E0432]: unresolved import `hello_world`
 --> src/main.rs:1:5
  |
1 | use hello_world::say_hi; fn main() { say_hi(); }
  |     ^^^^^^^^^^^ use of undeclared crate or module `hello_world`

For more information about this error, try `rustc --explain E0432`.
error: could not compile `hello-world` due to previous error
Error: 1 job failed

Now why do I want a main file? Easy - I want it to provide an app-specific CLI which I use during development.

feature: support SeaORM

ORMs offer a layer of abstraction which makes creating business logic a joy in web apps. Shuttle currently has native sqlx support but doesn't support any ORMs.

This feature would add SeaORM support and all the wiring required for it to work out of the box with the existing databases.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.