Hi! I’m looking into the current Nix setup and wanted to ask what the intended support scope is before opening any PR. Right now it looks like

flake.nix

has accumulated a lot of different responsibilities. It’s ~ 800 lines and includes both a dev shell and package outputs for CLI/Python/TypeScript, including debug/release, musl, and Darwin handling. As far as I can tell, all Nix logic lives in that one file; I don’t see a separate

nix/

structure, checks, formatter, docs, or Nix CI. It also seems to build from the older

engine/

workspace, while the current Rust dev docs point contributors to

baml_language/

. On top of that, the Linux dev shell looks currently broken because it references removed

pkgs.llvmPackages_17.libclang

.

.envrc

also auto-selects

use flake

whenever

nix-shell

exists, and it sets

RUSTC_WRAPPER=baml-sccache

, but the Nix shell doesn’t include

sccache

. So I’m wondering what maintainers want to do with Nix: 1. Keep it as dev-shell-only: then maybe simplify it, fix Linux/sccache, and remove or mark package outputs unsupported. 2. Support real packaging: then it probably needs a redesign around

baml_language/

, explicit supported systems, checks/CI, and a proper

nix/

structure. 3. Treat it as unofficial/best-effort or external: then maybe keep upstream minimal and let a separate

baml-nix

flake handle packaging. If upstream is interested in supported Nix packaging, I’d be willing to work on a refactor and split things into a

nix/

directory, similar in spirit to

packaging/aur

, instead of keeping everything inside one large

flake.nix

. Curious what direction you’d prefer.

hi! I'd actually love to see what we can do with shipping offical nix packages for BAML

I've created a issue and i'll make some PR soon. https://github.com/BoundaryML/baml/issues/4304

cc @baml-sam who's helping with community PRs!

Thanks for putting up the PR @Rhesus ! Will get this in as soon as we can I'm going to spend some time in an hour or two to understand this a bit better, but in the meantime - and these do not have to be solved to merge your PR! - I think the things I want to understand are: 1. do we need to add anything to CI to keep this green? (i think the answer is no) 2. what controls the Nix release cadence? (does it piggyback off our current release process?) 3. how does

baml.toml

tie into baml-cli versioning? (Rust has

rust-toolchain.toml

for this and Nix somehow solves this there)

Thanks, Here’s how the current PR is intended to work 1. CI There is no new CI or release-pipeline integration required for this PR to merge. However, i think ci check github action may required for stable releases. I intentionally exclude ci workflow on this PR because it needs some discussions.. (nix built artifact release and caching, .. etc.) I'll make some new thread in discord after this PR merged 2. Nix release cadence is managed by flake.lock, which is user pinned git revision lock file. If user does not execute

nix flake update

, baml version will not be changed. the revision can be pinned as follows: -

inputs.baml.url = github:BoundaryML/baml

-> follows current default branch revision and pinned -

inputs.baml.url = github:BoundaryML/baml/vX.Y.Z

-> follows release tag or branch 3. Nix does not interpret

baml.toml

or select the project toolchain itself. The Nix package installs the real

baml

wrapper with self-update disabled. At runtime, that wrapper reads the nearest project

baml.toml

, resolves its

[toolchain]

version/channel/path, installs the requested language toolchain under

BAML_HOME

when necessary, and then launches that toolchain’s

baml-cli

The separate Nix

baml-cli

package is a fixed CLI built from the pinned repository revision. It is intended for CI, containers, or other cases where the toolchain should be controlled entirely by Nix, and using it directly bypasses

baml.toml

toolchain selection.

rust-toolchain.toml

in the flake is unrelated to BAML project versioning: it only pins the Rust compiler used to build BAML.

> Nix release cadence is managed by flake.lock, which is user pinned git revision lock file. If user does not execute nix flake update, baml version will not be changed. the revision can be pinned as follows: > > inputs.baml.url = github:BoundaryML/baml -> follows current default branch revision and pinned > inputs.baml.url = github:BoundaryML/baml/vX.Y.Z -> follows release tag or branch Hmm- this makes me think that we should publish BoundaryML/baml-nix for Nix users then. Unfortunately the

vX.Y.Z

tags on the monorepo are being used by the older

engine/

releases, and we've also started doing the same for projects like Go, which for BAML v0 aka

engine/

we just released directly out of the monorepo but for BAML v1 we're releasing out of

BoundaryML/baml-go