Announcing the first release of Alice, a radical OCaml build system

Ecosystem
,
1

I’m pleased to announce the initial release of Alice, a radical, experimental OCaml build system, package manager, and environment manager for Windows, macOS, and Linux. Its goal is to allow anyone to program in OCaml with as little friction as possible.

To build your first program with Alice, run:

$ alice tools install   # Skip this if you already have an OCaml compiler!
$ alice new hello
$ cd hello
$ alice run
 Compiling hello v0.1.0
   Running hello/build/packages/hello-0.1.0/debug/executable/hello

Hello, World!

The UI is heavily inspired by Cargo.

An important distinction between Alice’s and Opam’s packaging philosophies is that in Alice, the OCaml compiler and development tools are not packages. The alice tools install command will install a pre-compiled (relocatable!) OCaml compiler, a compatible ocamllsp, and ocamlformat user-wide, similar to how rustup installs the Rust compiler and LSP server. This lets you go from zero to OCaml really fast because you don’t have to build the compiler from source. This speedup is particularly noticeable on Windows where building the compiler can take upwards of 10 minutes.

Alice supports building packages with dependencies on other packages, but currently only local packages are supported, and it can only build Alice packages, not Opam packages. See an example here. I’ll probably add Opam compatibility in the future.

It’s still early days and a lot is missing before Alice could feasibly be used for real projects.

If you want to try it out anyway, install the alice Opam package, the github:alicecaml/alice Nix flake, or run the interactive install script:

curl -fsSL https://alicecaml.org/install.sh | sh

More details about installing Alice are here.

If you want read more, check out the blog.

34 Likes
2

That’s likely not the feedback you are seeking for but I have to say, the logo is very cool :–) I’m deeply disturbed by the fact that it has a single hump but at least it’s not a horse.

4 Likes
3

This looks really cool. I’ll try it out. Pleasantly surprised that it’s written in OCaml and not Rust, given the trends nowadays!

4 Likes
4

While I’m not a fan of build systems that can only describe one language-specific exe/lib at a time (nor of the use of TOML), I admit that the workflow and toolchain management is exactly what OCaml is missing, so great job there! I’ll give it a try and keep an eye on how it evolves.

That’s mostly a trend among the Python/JS ecosystems, whose own languages are too slow for their own tooling.

3 Likes
5

This is really cool - I’m looking forward to getting some time to check it out!

1 Like
6

How does Alice discover dependencies and is it different from how dune does it? In particular, are discovery and build execution interleaved or is discovery and planning happening first and a plan is executed later (if that is even possible)?

1 Like
7

You may be as please as me to discover the 404 page features a camel without any humps https://www.alicecaml.org/404

11 Likes
8

In Alice discovery happens strictly before build execution. Alice uses ocamldep to compute a build plan which tracks interfile dependencies, and then it executes the build according to the plan.

4 Likes
9

This offers the option to compile this plan into a shell script that could be used to build the software somewhere where Alice is not installed - eg, for distribution in a package.

3 Likes
10

Exactly! Or a makefile, or a list of commands embedded in an opam file. This will simplify the bootstrapping story once Alice can build itself, and also will mean that when it becomes possible to publish Alice packages to opam, that Alice won’t need to be a dependency of such packages.

9 Likes
11

The camelids are a big family, and there is not reason for the llamas to be excluded :smiley:

4 Likes
12

That actually sound great :+1:

More choice beside dune/opam as newbies tend to confuse why they have to use one for package installation & dune for project setup/build… etc.

if Alice can unify that I guess I will no longer need to check version on every single one…

cargo/rust indeed was way too convenient that I feel spoiled :relieved_face: People need to realize Ocaml after Rust trend over.

I thought they should have praised Rust 5 years ago, maybe because of recent Linux adoption of rewriting a lot of libraries in Rust.

I have been also wondering about writing similar package/build system in Ocaml but for FASM :joy:

13

I like seeing alternatives out here… my first thoughts/impressions:

  $ alice tools install

That first line downloads an OCaml compiler toolchain and a couple of development tools (ocamllsp and ocamlformat).

This is the part I don’t like about Dune. I want a simple build tool that doesn’t do anything but easily & efficiently (“* No parallel builds (yet!).” would be great). I don’t want favoritism towards specific tools like ocamllsp or ocamlformat (that’s what the package manager is for & there are different/better options). If you are the type that is open to another build system, you probably are open to other tooling too which seems like dissonant addition.

Packages can only depend on other packages explicitly referred to within the local filesystem. There’s no package solver or registry and no way to download packages.

I don’t want package management features (that’s what the distro is for). Good!

It’s recommended to use direnv with the following .envrc

I appreciate that the project isn’t committing that .envrc so contributors can actually make modifications (Direnv was created for personal development, not teams/projects).

The alice executable will be installed to ~/.alice/alice/bin

It’s still early & yesterday was the time to support XDG Base Directory as many Linux users expect it & will be reporting it soon enough. It’s better to nip that in the bud before the directories become frozen & it takes years to have a migration plan (or sometimes project straight up say it is too late & unfeasible if too much time & tooling happens).

Not a huge fan of TOML. ocaml-kdl exists & KDL is much better IMO as a configuration format if modifications are required—where we can already see foo = { path = "../foo" } showing the nesting issues of TOML in this 5-line Alice.toml example.

The Nix code has some glaring issues to me (but much of the OCaml community is making similar mistakes). I raised an issue with one of the easy/obvious issues but it would have been nice if an account with Microsoft (GitHub) was required to file an issue; a mirror on a non-proprietary forge would be appreciated for user freedom as well as the possible users blocked by US sanctions.

4 Likes
14

Hey thanks for the detailed suggestions! I can certainly see about following the XDG spec. KDL looks cute. I just went with TOML because it’s what I know best coming from rust but I’ll do a proper review of the options at some point.

Can you elaborate on the Nix issues you see (here and elsewhere in OCaml)? I see you’ve raised an issue about my use of flake-utils. Was there anything else?

15

Buying into Flakes is very short-sighted the deeper anyone gets into Nix (I ranted on Reddit of all places about why). You want to expose an overlay which is both more compatible (doesn’t require experimental features) & more flexible (you can override both inputs & outputs in overlays), which the Flake pattern doesn’t lead most to. An alice namespace in an overlay with alice.package, alice.recommendTooling, & alice.full would probably be preferable (can’t namespace in flakes)—if not just alice with withRecommendedTooling overridable flag (I can’t quite tell just looking at it). On that tangent, packages (alice in this case) aren’t in individual files so I, as a user, could just grab the one thing I need instead of needing to importing & consuming a flake. Bash (assuming Zsh, Fish, etc. aren’t yet supported) completions should be a part of the postInstall of the package with an override flag instead of aliceMin (a separate file in package normal form would have led you down this as the preferred path). As well as, builtins.fetchGit lacks the hash, which pkgs.fetchgit or pkgs.fetchzip could get.

Again, these are common missteps & largely a result of buying into experimental, unversioned Flakes & the patterns it pushes users into that actually make the Nix output less flexible & less usable to downstream users & contributors.

1 Like
16

Makes sense, thanks for the nix packaging tips! I’ve never made a nix overlay before but I’ll investigate when I get some time.

17

You can re-expose stuff from a Classic Nix setup into Nix Flakes if you want users to have their choice—specifically if refactored into an overlay, you can just (in pseudo code) outputs.packages = inherit (pkgs) alice …; if overlayed onto Nixpkgs.

1 Like
18

I think a good property of KDL is that as the doc says " it looks like you’re invoking shell command". Of course they mean it uses the proper function call syntax.

More seriously, I think having syntax that feels familiar to users of the language you’re targeting is a good property, that sexp does not really provide.

1 Like
19

thanks you for create it, it looks very promising!

1 Like