PRQL
PRQL bindings for Elixir.
Installation
def deps do
[
{:prql, "~> 0.1.0"}
]
end
Basic Usage
iex> PRQL.compile("from customers")
{:ok, "SELECT\n *\nFROM\n customers\n\n-- Generated by PRQL compiler version 0.3.1 (https://prql-lang.org)\n"}
iex> PRQL.compile("from customers\ntake 10", dialect: :mssql)
{:ok, "SELECT\n TOP (10) *\nFROM\n customers\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 prql-compiler
.
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 RUST_FLAGS
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 passingRUST_FLAGS
(I’m actually unclear whyprql-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 onecargo build
from the terminal without either thetarget
ortarget_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 thatcargo
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, 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).
diff --git a/prql-elixir/native/prql/Cargo.toml b/prql-elixir/native/prql/Cargo.toml
index a39a9ee..218abad 100644
--- a/prql-elixir/native/prql/Cargo.toml
+++ b/prql-elixir/native/prql/Cargo.toml
@@ -17,7 +17,4 @@ path = "src/lib.rs"
[dependencies]
prql-compiler = {path = "../../../prql-compiler", default-features = false, version = "0.5.2"}
-
-# See Readme for details on Mac
-[target.'cfg(not(any(target_family="wasm", target_os = "macos")))'.dependencies]
rustler = "0.27.0"
diff --git a/prql-elixir/native/prql/src/lib.rs b/prql-elixir/native/prql/src/lib.rs
index 97eaa11..7525479 100644
--- a/prql-elixir/native/prql/src/lib.rs
+++ b/prql-elixir/native/prql/src/lib.rs
@@ -1,5 +1,3 @@
-// See Readme for more information on Mac compiling
-#![cfg(not(target_os = "macos"))]
// These bindings aren't relevant on wasm
#![cfg(not(target_family = "wasm"))]
// TODO: unclear why we need this `allow`; it's required in `CompileOptions`,