See #9. The theory here is that we might have a Ruby application that uses a gem implemented in Rust, and in order to compile the gem, the Ruby buildpack needs access to the Rust compiler.

To support this, we need to create an export file in our buildpack directory containing all the environment variables needed to run cargo and rustc.

Note that this still has some limitations: You almost certainly need to have a valid Cargo.toml in your project for the buildpack to detect and build before you can run the other buildpack that needs Rust.

• CC @binarycleric Feel free to take a look at this and let me know what you think.
• CC @schneems @elifoster Please let me know if this works for your use cases.

To try this, I think you can run heroku buildpacks:set https://github.com/emk/heroku-buildpack-rust#multirust_export and redeploy. But please set it back when you're done, because I'll delete the branch when I merge it.

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.

Previously this buildpack was trying to download and install rust manually which caused many stdlibs to be missing. Rust provides a script to automate a bunch of the install processes and switching to this greatly simplified the buildpack.

I tried it on a test app using iron and everything seemed to work correctly (https://github.com/binarycleric/resume-api). Forgive any bad code in that repo, I'm still learning Rust.

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

This does not rely upon any Rust toolchain support, but rather upon the good old find program. Thus, it copies all executables in $CARGO_TARGET_DIR/release, rather than any specifically-named executable file.

In short, this is a somewhat hacky method for circumnavigating #17.

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.

Something pretty similar to this is currently powering rusty-dash.com after I moved it over to Heroku last night/this morning. I think it should be backwards compatible with RustConfig's VERSION setup as well.

Fixes https://github.com/emk/heroku-buildpack-rust/issues/11

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

This line is one copied from a PR I found 2 years ago that never was merged. It is really awesome as it allows this buildpack to talk with a private GH repo in conjunction with this buildpack: https://github.com/heroku/heroku-buildpack-ssh-key.git

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!

• I had a problem when running compiled app on heroku: it wasn't able to find libnative library which is a part of rustc libs directory. After inspecting a slug I understood, that it has no build cache when dyno is running. Resolved issue by copying these libs inside of build directory and sourcing proper LD_LIBRARY_PATH.
• It was a pain to wait for dependencies to be re-downloaded through git and rebuilt from scratch at each deploy. So I put build artifacts (target and $cargo_home) to cache, and on next builds reusing it, so Cargo can decide what to download and what to rebuild on any updates in Cargo.lock file. Turns out that .git folders in cache survive between build perfectly.
• Since bin/compile is too bloated, I have refactored it to different bin/steps/* and call them from bin/compile.

Was upgrading an app that used https://github.com/Hoverbear/heroku-buildpack-rust before and got the error

-----> Checking for new releases of Rust stable channel        
/tmp/buildpacks/custom/bin/compile: line 107: rustup: command not found  

This fixes the rustup detection

When building with cargo build --example whatever, cargo places the resulting binary into target/release/examples/whatever. The find command's argument, maxdepth is set at 1, which excluded the examples directory. Changing this to 2 lets find look into the example directory.

Thought adding a general prefix to identify the variables wanted was simplest. Response to issue #25.

User sets Config Var for their Heroku application using the BUILDVAR_ prefix. These variables get exported similar to the DATABASE_URL for Diesel functionality.

$ heroku config:set BUILDVAR_KEY=mysecret

First time doing a contribution so please excuse but note any technical misses.

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!

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?