PRQL

PRQL bindings for Elixir.

Installation

  1. def deps do
  2.   [
  3.     {:prql, "~> 0.1.0"}
  4.   ]
  5. end

Basic Usage

  1.   iex> PRQL.compile("from customers")
  2.       {:ok, "SELECT\n  *\nFROM\n  customers\n\n-- Generated by PRQL compiler version 0.3.1 (https://prql-lang.org)\n"}
  5.   iex> PRQL.compile("from customers\ntake 10", dialect: :mssql)
  6.   {:ok, "SELECT\n  *\nFROM\n  customers\nORDER BY\n  (\n    SELECT\n      NULL\n  ) OFFSET 0 ROWS\nFETCH FIRST\n  10 ROWS ONLY\n\n-- Generated by PRQL compiler version 0.3.1 (https://prql-lang.org)\n"}

Development

We are in the early stages of developing Elixir bindings.

We’re using Rustler to provide Rust bindings for prqlc.

Currently using the bindings in an Elixir project requires compiling the Rust crate from this repo:

  • Install dependencies with mix deps.get
  • Compile project mix compile
  • Run tests mix test

Future work includes publishing pre-compiled artifacts, so Elixir projects can run PRQL without needing a Rust toolchain.

Mac

We currently don’t enable compilation for Mac. This is possible to enable, but causes some issues with cargo’s compilation cache. Briefly: it requires RUSTFLAGS to be set, and because of https://github.com/rust-lang/cargo/issues/8716 & https://github.com/rust-lang/cargo/issues/8899, any compilation of a different target will bust the cache.

The possible future workarounds include:

  • Passing --target=aarch64-apple-darwin to every cargo call, which is inconvenient and can be difficult in some situations; e.g. Rust Analyzer. This disables passing RUSTFLAGS (I’m actually unclear why prql-elixir builds successfully in that case…)
  • Directing other cargo calls to different paths, such as /target-ra for Rust Analyzer and /target-book for the book building. But one cargo build from the terminal without either the target or target_dir specified will bust the cache!
  • Never compiling for other targets. But our standard tests run for --target=wasm32-unknown-unknown, so this requires refraining from using them.
  • Removing prql-elixir from our workspace, so that cargo commands in the PRQL workspace don’t require rust flags. This would work well, but means we need separate test coverage for this crate, which adds some weight to the tests.

If prql-elixir becomes more used (for example, we start publishing to Hex, or Mac developers want to work on it), then we can re-enable and deal with the caching issues. We can also re-enable them if the cargo issue is resolved.

To test on Mac temporarily — for example if there’s an error in GHA and we’re on a Mac locally — apply a diff like this (though this specific diff is now out-of-date), and then run cargo build from the prql-elixir path, which will enable the local .cargo/config.toml). (We could also make a feature like elixir-mac which enabled building on Mac).

  1. diff --git a/prqlc/bindings/elixir/native/prql/Cargo.toml b/prqlc/bindings/elixir/native/prql/Cargo.toml
  2. index 7194ca4f..9c7240ff 100644
  3. --- a/prqlc/bindings/elixir/native/prql/Cargo.toml
  4. +++ b/prqlc/bindings/elixir/native/prql/Cargo.toml
  5. @@ -19,5 +19,5 @@ path = "src/lib.rs"
  6.  prql-compiler = {path = "../../../../prql-compiler", default-features = false, version = "0.6.1"}
  8.  # See Readme for details on Mac
  9. -[target.'cfg(not(any(target_family="wasm", target_os = "macos")))'.dependencies]
  10. +# [target.'cfg(not(any(target_family="wasm", target_os = "macos")))'.dependencies]
  11.  rustler = "0.27.0"
  12. diff --git a/prqlc/bindings/elixir/native/prql/src/lib.rs b/prqlc/bindings/elixir/native/prql/src/lib.rs
  13. index 2c5c8f27..68e77217 100644
  14. --- a/prqlc/bindings/elixir/native/prql/src/lib.rs
  15. +++ b/prqlc/bindings/elixir/native/prql/src/lib.rs
  16. @@ -1,5 +1,5 @@
  17.  // See Readme for more information on Mac compiling
  18. -#![cfg(not(target_os = "macos"))]
  19. +// #![cfg(not(target_os = "macos"))]
  20.  // These bindings aren't relevant on wasm
  21.  #![cfg(not(target_family = "wasm"))]
  22.  // TODO: unclear why we need this `allow`; it's required in `CompileOptions`,