emk / heroku-buildpack-rust Goto Github PK

View Code? Open in Web Editor NEW

519.0 15.0 184.0 63 KB

A buildpack for Rust applications on Heroku, with full support for Rustup, cargo and build caching.

Shell 100.00%

heroku-buildpack-rust's Introduction

Heroku buildpack for Rust

This is a Heroku buildpack for Rust with support for cargo and rustup. Features include:

Caching of builds between deployments.
Automatic updates to the latest stable Rust by default.
Optional pinning of Rust to a specific version.
Support for export so that other buildpacks can access the Rust toolchain.
Support for compiling Rust-based extensions for projects written in other languages.

Example projects

Here are several example projects:

rust-buildpack-example-actix uses the popular Actix framework, and runs on stable Rust.
rust-buildpack-example-rocket uses the innovative Rocket framework, which currently requires nightly Rust.

Using this buildpack

To deploy an application to Heroku, we recommend installing the Heroku CLI.

If you're creating a new Heroku application, cd to the directory containing your code, and run:

heroku create --buildpack emk/rust

This will only work if your application has a Cargo.toml and uses git. If you want to set a particular name for application, see heroku create --help first.

To use this as the buildpack for an existing application, run:

heroku buildpacks:set emk/rust

You will also need to create a Procfile pointing to the release version of your application, and commit it to git:

web: ./target/release/hello

...where hello is the name of your binary.

To deploy your application, run:

git push heroku master

Running Diesel migrations during the release phase

This will install the diesel CLI at build time and make it available in your dyno. Migrations will run whenever a new version of your app is released. Add the following line to your RustConfig

RUST_INSTALL_DIESEL=1

and this one to your Procfile

release: ./target/release/diesel migration run

Specifying which version of Rust to use

By default, your application will be built using the latest stable Rust. Normally, this is pretty safe: New stable Rust releases have excellent backwards compatibility.

But you may wish to use nightly Rust or to lock your Rust version to a known-good configuration for more reproducible builds. To specify a specific version of the toolchain, use a rust-toolchain file in the format rustup uses.

Note: if you previously specified a VERSION variable in RustConfig, that will continue to work, and will override a rust-toolchain file.

Combining with other buildpacks

If you have a project which combines both Rust and another programming language, you can insert this buildpack before your existing one as follows:

heroku buildpacks:add --index 1 emk/rust

If you have a valid Cargo.toml in your project, this is all you need to do. The Rust buildpack will run first, and your existing buildpack will run second.

But if you only need Rust to build a particular Ruby gem, and you have no top-level Cargo.toml file, you'll need to let the buildpack know to skip the build stage. You can do this by adding the following line to RustConfig:

RUST_SKIP_BUILD=1

Customizing build flags

If you want to change the cargo build command, you can set the RUST_CARGO_BUILD_FLAGS variable inside the RustConfig file.

RUST_CARGO_BUILD_FLAGS="--release -p some_package --bin some_exe --bin some_bin_2"

The default value of RUST_CARGO_BUILD_FLAGS is --release. If the variable is not set in RustConfig, the default value will be used to build the project.

Using the edge version of the buildpack

The emk/rust buildpack from the Heroku Registry contains the latest stable version of the buildpack. If you'd like to use the latest buildpack code from this Github repository, you can set your buildpack to the Github URL:

heroku buildpacks:set https://github.com/emk/heroku-buildpack-rust

Development notes

If you need to tweak this buildpack, the following information may help.

Testing with Docker

To test changes to the buildpack using the included docker-compose-test.yml, run:

./test_buildpack

Then make sure there are no Rust-related *.so files getting linked:

ldd heroku-rust-cargo-hello/target/release/hello

This uses the Docker image heroku/cedar, which allows us to test in an official Cedar-like environment.

We also run this test automatically on Travis CI.

heroku-buildpack-rust's People

Contributors

Stargazers

Watchers

Forkers

andor44 omarkj ryman johnmq kumabook dbalchev havardh ealasu josephglanville rhelmer tomprince binarycleric jsaindon bartoszkopinski alexpikalov dhobbs steveklabnik alexcrichton matthew-piziak halcyon nashenas88 bluejekyll ivanceras szhaoyu yoshitsugu ivarvong naufraghi hone icode-live hivesbee foodgambit realli ayazhafiz saks leviatan-12 bjorn3 tonsser pusherofbrooms vorticity-flux jwong8314 freemasen andy-bell b-boogaard nrxus otterandrye agrinman jkutner kot9 genya0407 alsuren davidpdrsn georgerogers42 dignifiedquire mattrutherford leorowan robinvd watercycle pedrohjordao ekump mastfissh cbrewster fatkhur1960 gewmas steven-holloway mndeal jstarry boscop solana-labs vova616 mobility46 zmackie burntcaramel danipozo ndobrovolsky mackwic tiger10050 fahdw pro-boys vvorlov nellshamrell tabris-ai crajcan rusty-light-cycle harri88 kvnallsn dopin rot1024 benlellouch kamieen03 mmfan muyopongo actongorton wh75er alphagov 0atman sdunifon vini-fda qalens edmellum vmarkushin

heroku-buildpack-rust's Issues

Cannot find lsqlite3

When building an actix_web-based application with this buildpack, we've recently been running into a compile-time issue related to lsqlite3. Here's the abbreviated output of the error we're getting:

error: linking with `cc` failed: exit code: 1

 // snip

  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L"
  = note: /usr/bin/ld: cannot find -lsqlite3

          collect2: error: ld returned 1 exit status

We are not seeing any similar linking issues when building from the latest rust docker containers using heroku.yml, so this might have something to do with the heroku-18 stack.

Build failing on Heroku

I'm getting odd build errors using this buildpack on Heroku:

-----> Rust app detected
-----> Checking for new releases of Rust 1.25.0 channel
/app/tmp/buildpacks/2203aab785e02c47ff95174d7e631633e83fa90010efce9a5d8ac8a35661280d39a58ff430859981c23547da7ff13b84a22749dc31aa7bcc3283c9678757b447/bin/compile: line 98: rustup: command not found
 !     Push rejected, failed to compile Rust app.
 !     Push failed

I've run the test script with the same repository locally with docker, and it works fine. I've also tried deploying the test app, and that seems OK apart from the issue I filed; it gets further than this though.

I'm at a bit of a dead end working out why this is happening. Any ideas?

How to include node?

Hi @emk,

sorry for hijacking the issue tracker for this off topic question but I was wondering if you could give me advice on how to modify the buildpack to include node? I've never created a buildpack before so I'm happy for any pointers.

Cheers,

Christoph

Support for `WEB_CONCURRENCY`

This buildpack doesn't set the WEB_CONCURRENCY environment variable. For example, the official Python buildpack sets it. I'm guessing that this is set by Heroku themselves, and the buildpacks just expose it. Here's a link that mentions the use of WEB_CONCURRENCY for Python.

Could you look into this, and add support if it's feasible and makes sense for Rust servers?

Not able to build nightly

When I specify the buildpack to use nightly, I get this on heroku:

-----> Rust app detected
-----> Downloading rustup
-----> Using rustup to install Rust channel nightly
info: downloading installer
error: invalid toolchain name: 'nightly
 !     Push rejected, failed to compile Rust app.
 !     Push failed

nightly rust distributions go with cargo included

Worked around by:

mkdir -p cache/cargo-cache-nightly
cd cache/cargo-cache-nightly
ln -s ../rust-cache-nightly/rust-nightly-x86_64-unknown-linux-gnu cargo-nightly-x86_64-unknown-linux-gnu

Also my RustConfig contains:

URL="https://static.rust-lang.org/dist/rust-nightly-x86_64-unknown-linux-gnu.tar.gz"
VERSION="nightly"

Cannot find diesel during Heroku release step

Hi, I think I have followed all the steps to run Diesel migrations on release with Heroku correctly but I keep getting this error in Heroku deploys:

/bin/sh: 1: ./target/release/diesel: not found

It seems the step which is supposed to install the diesel-cli does not seem to run. These are my RustConfig and Procfile:

VERSION=nightly
RUST_INSTALL_DIESEL=1

release: ./target/release/diesel migration run

Is there something I missed in the setup?

rustup uses stable at first deploy, ignoring RustConfig's $VERSION

https://github.com/emk/heroku-buildpack-rust/blob/master/bin/compile#L86-L93

Add support for custom ssh keys

Due to how cargo uses ssh keys, it is required to run

eval $(ssh-agent -s)
ssh-add $HOME/.ssh/my_key

before executing the install step, if there are any keys present that need to be used. There are a couple of build packs for heroku that allow to setup the key, but adding those lines above to this buildpack are required to make it work as I found out.

Timeout on Build

Hi guys, I'm trying to deploy an api made with actix and I'm having problems with timeout during build, does anyone know how I can increase this timeout or how to solve my problem ? print of the log: https://twitter.com/KindSloth/status/1408551910123126785/photo/1

Cannot get nightly to build

Hello,
I have looked at other issues, but none of the solutions worked.

I am trying to get the nightly to build on Heroku, because of Rocket.rs.
I have specified a RustConfig file, a rust-toolchain file, a RUSTUP_TOOLCHAIN env var both on Heroku and my machine. Nothing worked so far.
I also set rustup to default to the nightly on my machine.
I can see the build is always picking up stable. Nonetheless, nothing in my app seems to specify it.

The example works fine though. Any pointers ?
Thanks!

Build is failing, need help to figure this out

Build log on Heroku is :

-----> Rust app detected
-----> Downloading rustup
-----> Using rustup to install Rust channel beta
info: downloading installer
error: invalid toolchain name: 'beta
 !     Push rejected, failed to compile Rust app.
 !     Push failed

So, why is it 'beta instead of beta?

RustConfig :
VERSION="beta"

If you need more info, I can give it! Thanks for the help!

VERSION=1.X not supported anymore

Despite what the README says, setting e.g "VERSION=1.20" doesn't work. You get

-----> Downloading rustup
-----> Using rustup to install Rust channel 1.20
info: downloading installer
error: invalid toolchain name: '1.20'
 !     Push rejected, failed to compile Rust app.
 !     Push failed```

Make (certain) environment variables available at build time

Right now, this buildpack always builds with --release. But there are situations in which one might want to build in debug mode... or at least with debug symbols enabled.

Maybe this could be added as a configuration in RustConfig?

Remove build artifacts after the build process?

Heroku has a limit of 300 MB for the slug size (ie. the output of the build process).

Unfortunately I've run into an annoying problem this morning, which is that running cargo build --release creates a target directory that weights 310 MB, though the actual binary itself is only 41 MB.

Heroku's docs suggest that you use a .slugignore file (similar to a .gitignore). However the files that match .slugignore are removed before the build process, so it's useless in my situation.

I don't know if you have a solution to suggest for me and people who run in the same situation as me? Removing the /target/release/deps in the buildpack would be nice, but as I'm not familiar with heroku's caching process I don't know if it's a good idea to do so.

Cache cargo builds

Now that we have a modern environment working (rustup and cargo), we really ought to consider doing something about the fact that we rebuild the application from scratch on every deploy. There is some code in #2 that sets up cached builds, but it predates the merge of #8.

This is the "last" major missing feature that I think this buildpack needs to be top-quality.

Allow developer to specify a channel instead of a specific rust version

It'd be helpful to have a way to specify CHANNEL="nightly", CHANNEL="beta", or CHANNEL="stable" instead of locking onto a specific version

Need help! Error R10 - Boot timeout -> failed to bind to $PORT within 60 seconds

The build succeeds. I am using actix-web 0.7, diesel 1.4.2. This is my repo. Here's what the Heroku logs have to say about my error. I am binding to the correct PORT it seems that is set in the env variables. Once I release for 60 seconds I can try to access the API endpoints, but for this time I can't connect. I get a spinning circle and once the time passes I get an Application Error response in the browser.

Starting process with command `./target/release/dziennik-rust` 
Apr 20 05:10:15 dziennik-rust app/web.1:  DEBUG dziennik_rust > Listening on 127.0.0.1:21674 
Apr 20 05:10:16 dziennik-rust app/web.1:  INFO  actix_net::server::server > Starting 8 workers 
Apr 20 05:10:16 dziennik-rust app/web.1:  INFO  actix_net::server::server > Starting server on 127.0.0.1:21674 
Apr 20 05:10:16 dziennik-rust app/web.1:  DEBUG tokio_reactor             > adding I/O source: 0 
Apr 20 05:10:16 dziennik-rust app/web.1:  DEBUG tokio_reactor             > adding I/O source: 4194305 
Apr 20 05:10:16 dziennik-rust app/web.1:  DEBUG tokio_reactor             > adding I/O source: 8388610 
Apr 20 05:10:16 dziennik-rust app/web.1:  DEBUG tokio_reactor             > adding I/O source: 12582915 
Apr 20 05:10:16 dziennik-rust app/web.1:  DEBUG tokio_reactor             > adding I/O source: 16777220 
Apr 20 05:10:16 dziennik-rust app/web.1:  DEBUG tokio_reactor::registration > scheduling Read for: 0 
Apr 20 05:10:16 dziennik-rust app/web.1:  DEBUG tokio_reactor::registration > scheduling Read for: 1 
Apr 20 05:10:16 dziennik-rust app/web.1:  DEBUG tokio_reactor::registration > scheduling Read for: 2 
Apr 20 05:10:16 dziennik-rust app/web.1:  DEBUG tokio_reactor::registration > scheduling Read for: 3 
Apr 20 05:10:16 dziennik-rust app/web.1:  DEBUG tokio_reactor::registration > scheduling Read for: 4 
Apr 20 05:10:48 dziennik-rust heroku/web.1: State changed from crashed to starting 
Apr 20 05:11:14 dziennik-rust heroku/web.1: State changed from starting to crashed 
Apr 20 05:11:14 dziennik-rust heroku/web.1: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch 
Apr 20 05:11:14 dziennik-rust heroku/web.1: Stopping process with SIGKILL

I don't think it's the problem, but I got this error on Sentry. It happened only once, but I tried releasing much more often than that, so I don't think that's the problem. I have used heroku local to bind to the PostgreSQL database on Heroku's AWS and it all works fine. It's just that it doesn't work on Heroku.

Can it be this? I am leveraging auto reload with listenfd. Maybe it's somehow blocking Heroku from recognising the correct port?

Specify desired Rust version using `Cargo.toml` `[metadata]` section with `rustup_channel`?

Right now, we use a RustConfig file to specify the VERSION we want to use. This adds one more unnecessary bit of clutter to a project repo.

There's a discussion of this at rust-lang/cargo#1214 (closest) and rust-lang/cargo#837 (upstream tracking issue).

But Cargo has a [metadata] section we could use, as shown here. It would be great to add a rustup_channel to this file:

[metadata]
rustup_channel="stable"

We could use cargo read-manifest to convert this to JSON on standard output. However, I'm not sure whether Heroku's build envrionment has any good JSON-parsing tools, so this might not actually get us any closer. Would it be reasonable/possible to install a tool like jq at build time on Heroku to parse the JSON for us, or is this overkill?

In theory, Rustup might someday decide to support a standard way of specifying which version of Rust to use with a given project. The tracking bug for this is at rust-lang/rustup#460.

error: reached the type-length limit

What happened this morning? Locally everything is fine, but on deployment (my app is vzmuinebot has no significant changes from yesterday):

-----> Rust app detected
-----> Checking for new releases of Rust stable channel
info: checking for self-updates
  rustup unchanged - 1.22.1
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: latest update on 2020-08-27, rust version 1.46.0 (04488afe3 2020-08-24)
info: downloading component 'cargo'
info: downloading component 'clippy'
info: downloading component 'rust-docs'
info: downloading component 'rust-std'
info: downloading component 'rustc'
info: downloading component 'rustfmt'
info: removing previous version of component 'cargo'
info: removing previous version of component 'clippy'
info: removing previous version of component 'rust-docs'
info: removing previous version of component 'rust-std'
info: removing previous version of component 'rustc'
info: removing previous version of component 'rustfmt'
info: installing component 'cargo'
info: Defaulting to 500.0 MiB unpack ram
info: installing component 'clippy'
info: installing component 'rust-docs'
info: installing component 'rust-std'
info: installing component 'rustc'
info: installing component 'rustfmt'
  stable-x86_64-unknown-linux-gnu updated - rustc 1.46.0 (04488afe3 2020-08-24) (from rustc 1.45.2 (d3fb005a3 2020-07-31))
info: checking for self-updates
info: using existing install for 'stable-x86_64-unknown-linux-gnu'
info: default toolchain set to 'stable-x86_64-unknown-linux-gnu'
  stable-x86_64-unknown-linux-gnu unchanged - rustc 1.46.0 (04488afe3 2020-08-24)
-----> Building application using Cargo
    Updating crates.io index
   Compiling libc v0.2.76
   Compiling cfg-if v0.1.10
   Compiling proc-macro2 v1.0.19
[skip]
   Compiling reqwest v0.10.8
   Compiling teloxide v0.2.0
   Compiling vzmuinebot v0.5.2 (/tmp/build_561df862)
error: reached the type-length limit while instantiating `std::future::from_generator::<[s...g::Dispatcher]>, ()}]>}]>, ()}]>`
   |
   = note: consider adding a `#![type_length_limit="3987824"]` attribute to your crate
error: aborting due to previous error
error: could not compile `vzmuinebot`.
To learn more, run the command again with --verbose.
 !     Push rejected, failed to compile Rust app.
 !     Push failed

Option to keep source files of dependencies after compile

I happen to be using a cargo package in my app that reads some local (to the package) files at runtime. When I run my app using this build-pack, I get errors that those files no longer exist.

Would it be possible to add an ENV var (or something similar) to prevent the build-pack from deleting source files after compilation?

Ruby/Rust ld cannot find lruby

I've built a Ruby/Rust hello application, but it does not want to deploy to Heroku. @schneems

remote:        Gem::Ext::BuildError: ERROR: Failed to build gem native extension.
remote:        
remote:        current directory: /tmp/build_b49520d155f32d44a5ec710ef7b84985/vendor/bundle/ruby/2.3.0/gems/string-utility-2.7.3/ex
remote:        /tmp/build_b49520d155f32d44a5ec710ef7b84985/vendor/ruby-2.3.0/bin/ruby -r ./siteconf20160926-228-cc92i.rb extconf.rb
remote:        cargo 0.12.0-nightly (6b98d1f 2016-07-04)
remote:        rustc 1.11.0 (9b21dcd6a 2016-08-15)
remote:        
remote:        current directory: /tmp/build_b49520d155f32d44a5ec710ef7b84985/vendor/bundle/ruby/2.3.0/gems/string-utility-2.7.3/ex
remote:        make "DESTDIR=" clean
remote:        rm -rf target
remote:        
remote:        current directory: /tmp/build_b49520d155f32d44a5ec710ef7b84985/vendor/bundle/ruby/2.3.0/gems/string-utility-2.7.3/ex
remote:        make "DESTDIR="
remote:        cargo build --release
remote:        Updating registry `https://github.com/rust-lang/crates.io-index`
remote:        Downloading ruru v0.7.8
remote:        Downloading ruby-sys v0.2.13
remote:        Downloading libc v0.2.16
remote:        Compiling ruby-sys v0.2.13
remote:        Compiling libc v0.2.16
remote:        Compiling ruru v0.7.8
remote:        Compiling string-utility-rb-native v1.0.0 (file:///tmp/build_b49520d155f32d44a5ec710ef7b84985/vendor/bundle/ruby/2.3.0/gems/string-utility-2.7.3/ext)
remote:        src/lib.rs:4:12: 4:21 warning: unused import, #[warn(unused_imports)] on by default
remote:        src/lib.rs:4 use ruru::{AnyObject, Class, RString, VM};
remote:        ^~~~~~~~~
remote:        src/lib.rs:4:39: 4:41 warning: unused import, #[warn(unused_imports)] on by default
remote:        src/lib.rs:4 use ruru::{AnyObject, Class, RString, VM};
remote:        ^~
remote:        src/lib.rs:5:19: 5:23 warning: unused import, #[warn(unused_imports)] on by default
remote:        src/lib.rs:5 use ruru::types::{Argc, Value};
remote:        ^~~~
remote:        src/lib.rs:5:25: 5:30 warning: unused import, #[warn(unused_imports)] on by default
remote:        src/lib.rs:5 use ruru::types::{Argc, Value};
remote:        ^~~~~
remote:        src/lib.rs:6:5: 6:25 warning: unused import, #[warn(unused_imports)] on by default
remote:        src/lib.rs:6 use ruru::traits::Object;
remote:        ^~~~~~~~~~~~~~~~~~~~
remote:        error: linking with `cc` failed: exit code: 1
remote:        note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/app/tmp/cache/multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/tmp/build_b49520d155f32d44a5ec710ef7b84985/vendor/bundle/ruby/2.3.0/gems/string-utility-2.7.3/ext/target/release/stringutility.0.o" "-o" "/tmp/build_b49520d155f32d44a5ec710ef7b84985/vendor/bundle/ruby/2.3.0/gems/string-utility-2.7.3/ext/target/release/libstringutility.so" "/tmp/build_b49520d155f32d44a5ec710ef7b84985/vendor/bundle/ruby/2.3.0/gems/string-utility-2.7.3/ext/target/release/stringutility.metadata.o" "-Wl,-O1" "-nodefaultlibs" "-L" "/tmp/build_b49520d155f32d44a5ec710ef7b84985/vendor/bundle/ruby/2.3.0/gems/string-utility-2.7.3/ext/target/release" "-L" "/tmp/build_b49520d155f32d44a5ec710ef7b84985/vendor/bundle/ruby/2.3.0/gems/string-utility-2.7.3/ext/target/release/deps" "-L" "/app/vendor/ruby-2.3.1/lib" "-L" "/app/tmp/cache/multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "-Wl,--whole-archive" "/tmp/rustc.q8eAleDtOvmp/libruru-35c12ee1cec9de02.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.q8eAleDtOvmp/libruby_sys-a3c0096998cfe6fb.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.q8eAleDtOvmp/liblibc-1417726cb94dbc83.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.q8eAleDtOvmp/libstd-39b92f95.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.q8eAleDtOvmp/libpanic_unwind-39b92f95.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.q8eAleDtOvmp/libunwind-39b92f95.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.q8eAleDtOvmp/librand-39b92f95.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.q8eAleDtOvmp/libcollections-39b92f95.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.q8eAleDtOvmp/librustc_unicode-39b92f95.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.q8eAleDtOvmp/liballoc-39b92f95.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.q8eAleDtOvmp/liballoc_system-39b92f95.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.q8eAleDtOvmp/liblibc-39b92f95.rlib" "-Wl,--no-whole-archive" "-Wl,--whole-archive" "/tmp/rustc.q8eAleDtOvmp/libcore-39b92f95.rlib" "-Wl,--no-whole-archive" "-l" "ruby" "-l" "util" "-l" "dl" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "util" "-shared" "-l" "compiler-rt"
remote:        note: /usr/bin/ld: cannot find -lruby
remote:        collect2: error: ld returned 1 exit status
remote:        
remote:        error: aborting due to previous error
remote:        error: Could not compile `string-utility-rb-native`.
remote:        
remote:        To learn more, run the command again with --verbose.
remote:        make: *** [all] Error 101
remote:        
remote:        make failed, exit code 2
remote:        
remote:        Gem files will remain installed in /tmp/build_b49520d155f32d44a5ec710ef7b84985/vendor/bundle/ruby/2.3.0/gems/string-utility-2.7.3 for inspection.
remote:        Results logged to /tmp/build_b49520d155f32d44a5ec710ef7b84985/vendor/bundle/ruby/2.3.0/extensions/x86_64-linux/2.3.0-static/string-utility-2.7.3/gem_make.out
remote:        An error occurred while installing string-utility (2.7.3), and Bundler cannot
remote:        continue.
remote:        Make sure that `gem install string-utility -v '2.7.3'` succeeds before bundling.

Add instructions on how to use sqlx migrations

If someone wants to use sqlx instead of Diesel, it would be nice to see instructions on how to do that in the README.

Cargo missing?

Hi,

I've seen some related issues to this (#6 and others) but they're fairly old and potentially out of date and the fixes there don't seem to help/aren't relevant anymore.

I'm using Rust + Elixir in an app for the purpose of using Meeseeks/html5ever. The Elixir buildpack, when compiling a nif, cannot find cargo (build output here: https://pastebin.com/raw/aMnPU6hM)

After some experimenting, I'm seeing that during the Elixir buildpack's "run this before fetching dependencies" callback, the /app/tmp/cache directory doesn't contain a cargo directory, as indicated by the output of this buildpack. See heroku output here, ls command is at the bottom: https://pastebin.com/raw/kC0MyxSp

Am I misunderstanding how this works?

Here's my buildpack setup in Heroku, if it's helpful:

Thanks in advance for any input.

Old targets are left behind

A few months ago, I change the name for a bin in my Cargo.toml, as the resulting binary name wasn't compatible with something (needed underscores instead of hyphens for some reason). The binary with the old name however, is still floating around in the slug. The Procfile references the new name, so it's not picking up the wrong file, but the old file is still there. I had a look through the code in compile, and it looked like the target directory was being cleaned up, but I'm not sure if it's the right one.

It's my understanding that the buildpack should take care of this. I've seen various solutions involving clearing build caches and resetting repos, and I suspect the latter might work, but seems like overkill.

Build failing because of openssl

I don't know if this is the right place to report this, but it compiles on my machine and doesn't when I try to push. I'm getting this error:

Compiling serde_codegen_internals v0.14.2

error: failed to run custom build command for `openssl v0.9.24`
Caused by:
  process didn't exit successfully: `/app/tmp/cache/target/release/build/openssl-6cb40b2d37c6afdc/build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'Unable to detect OpenSSL version', /app/tmp/cache/cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/build.rs:16:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
warning: build failed, waiting for other jobs to finish...
error: build failed

 !     Push rejected, failed to compile Rust app.
 !     Push failed

If there is any info I forgot to include please let me know.

Edit: solved by adding heroku-buildpack-openssl before the rust buildpack.

Ruby application with Rust dependencies

I've got a gem, string-utility, which is written in Rust using ruru for a few of its methods. I am trying to use this buildpack to install Rust and Cargo (without running cargo build, I can just fork the project and remove that tiny amount of code since it's a pretty uncommon desire at this point I'd imagine). However, it seems, even if the Rust buildpack runs successfully, Bundler is unable to find cargo or rustc to compile string-utility's Rust code. There was a similar question #6, except that question was regarding a project that was written with Node and Rust, not Node with Rust dependencies. In other words, it actually wanted to compile Rust code, then run Node separately. I've been trying to figure this out through experimentation and talking with Heroku support, and I've been unsuccessful for about 3 weeks. The majority of my projects depend on this library, and chances are, once I figure this out, many of my other libraries are going to be rewritten partially in Rust.

I'm not really sure how to briefly ask what I'm trying to ask here. I suppose:

Is using this buildpack the correct way to get Rust/Cargo installed on a Heroku project?
If so, how can I get it to install such that Bundler can actually find it, or is that a bug in the buildpack?

My buildpack order: 1. emk/heroku-buildpack-rust, 2. heroku/ruby

Add support for Trunk

Hi, buildpack newbie here, so please apologise if I'm mistaken.

I believe a Rust buildpack should support Trunk, the application bundler recommended for Yew - a rather popular WASM framework.

Thanks!

Not detecting nightly?

I have a project that needs nightly (or beta)...

I have a Rustconfig file with this in it:

VERSION=nightly

yet the buildpack still tries to use stable. Am I doing something wrong? I was looking at the code, i dunno.

Customize builds with `cargo --features`

It would be great if you could set cargo --features <FEATURES> somehow when pushing to heroku.

How to compile WASM?

Can we use this to comiple WASM, eg with cargo make? Stated another way, can we have it run cargo make build (etc) on launch, where the corresponding Makefile knows how to build the wasm modules?

Register in buildpack registry

My name is Jon Byrum and I’m a product manager at Heroku. Your buildpack is one of the top 200 most popular buildpacks on Heroku!

I would like to invite you to publish your buildpack early in our Buildpack Registry, before it is made available to the general public (expected early July).

To register your buildpack, visit: https://addons-next.heroku.com/buildpacks
Documentation: https://devcenter.heroku.com/articles/buildpack-registry

Why register?

By registering early you’ll be able to grab your preferred namespace for the buildpack
After registering, your buildpack will be available to all Heroku users when they run heroku buildpacks:search. In the future, we will only display registered buildpacks on elements.heroku.com/buildpacks
The Buildpack Registry makes it easy for you to publish a new version of your buildpack, as well as roll back if there are errors

Recommended naming conventions:

We recommend that you use the same namespace (e.g., jbyrum) with Buildpack Registry that you use on GitHub
In general, avoid using "buildpack" in the name of your registered buildpack
- For example: If your Github repo is github.com/foobar/heroku-buildpack-elixir, then we recommend a name like "foobar/elixir"

It would be greatly appreciated if you could publish before June 18th, as we prepare to make the feature publicly available. Registering a buildpack should take approximately 5 minutes.

If you have any questions about registering (or run into any issues), please email:
[email protected]