Tried to get started with nix and had a pretty terrible time of it. Gave up in the end. But I know there are people building ocaml software with nix and without opam. That seems like a pretty big deal to me. Kinda subverts the whole “OCaml Platform” story. Do you use nix without opam? It would be nice to know how many of you there are.
1 Like
I’ve been using ocaml in personal projects for a few years now, and I’ve actually never (directly) interacted with opam.
My workflow is based not on nix but on Guix, which shares some of the same goals and concepts. One thing it doesn’t share is nix’s goofy bespoke config language; it instead uses Guile Scheme to define packages, profiles, etc.
The selection of ocaml packages bundled with Guix is likely smaller than nix’s, but the Guix CLI has a command to derive a new package from the corresponding opam package metadata. If the package uses Dune and follows basic build conventions, the auto-generated package often works with little or no manual tweaking.
The main caveat is that the ocaml package definitions in Guix haven’t seen many updates since ocaml 5.0. I believe this is not for technical reasons, but because certain package maintainers have moved on. (It’s a much smaller community than nix’s.)
4 Likes
@conroj guix always felt more appealing than nix (or brew) as a language agnostic package manager for development. Do you know if there is any effort to port it to more platforms ? Last time I checked it was decidedly linux only.
I use Nix with Opam, since I miss version solving in language ecosystems.
I interoperate between Nix and Opam in two ways;
- For development, I’ve got a PR adding depext support to Opam with Nix. This creates a “nix shell” that Opam manages to provide system dependencies with Nix. I think this could be useful on Non-NixOS distributions too; to provide system dependencies without mutating your global state.
I prefer this to using a Nix shell for development since the Nix tooling is slow and unwieldy, and doesn’t support solving dependency versions. But it’s great for reproducible deployments (and I use it to manage most of my machines), so - For deployment, I use opam-nix, which creates a Nix derivation from an Opam project. It does an Opam solve in a Nix derivation, and uses ‘import from derivation’ (IFD) to then create derivations for all the solved dependencies.
You can also use this to create Nix derivations for MirageOS unikernels with hillingar.
I’m aware of people who use OCaml with Nix without Opam, e.g. github.com/nix-ocaml/nix-overlays.
3 Likes
@conroj
guixalways felt more appealing thannix(orbrew) as a language agnostic package manager for development. Do you know if there is any effort to port it to more platforms ? Last time I checked it was decidedly linux only.
Technically Guix also supports Hurd, but yes, pretty much everyone uses Linux. The project founder has taken the position that supporting platforms without glibc is possible in principle but really difficult to do well - i.e. with comparable support across libcs. That’s link is pretty old, but I don’t think the position has changed.
1 Like
Guix is GPL licensed, is it not? What does that mean for projects built using it?
Found this intriguing critter: GitHub - rizo/onix: Build OCaml projects with Nix.. Anybody using it?
GNU Make is GPL licensed.
Guix is GPL licensed, is it not? What does that mean for projects built using it?
Standard disclaimers apply (I am not a lawyer), but as far as I know there is no impact.
The GPL stipulates how you must license derivative works of existing GPL code. But the scripts and patches comprising a Guix package definition are, if anything, the reverse of that: a GPL-licensed work based on another OSS package.
And even then, I’m not sure whether build scripts and patches for a piece of code really meet the definition of a “derivative work” in the way that linking against the code or redistributing a modified version does.
Hi! As the author of onix, I do use it in a significant number production and hobby projects.
I’ve used opam-nix and opam2nix before deciding to build onix. My main motivation was to implement a very thin layer on top of opam (and compatible with opam) centered around a simple lock-file format, with reasonable cross-project caching.
Generally speaking, the glue required to make nix work with opam is somewhat fragile. The mental model of opam is fundamentally incompatible with nix: everything is global, mutable and with very loose build/runtime dependency classification.
Having said that, I still prefer using onix to managing opam switches. Once an onix project is set up, I rarely have to think about deps. My workflow is: make lock to create a lock file from opam files and make shell to build all the deps and load a shell ready to build the project. It’s clunky and the abstraction leaks when you try to build packages that don’t follow the “rules”, but for me, having reproducibility makes it worthwhile.
My hope is that dune pkg can subsume package resolution and lock-file management in the next generation of nix-focused tools (which is the way it works with nix tools that target Cargo, for example). The work on cross-compilation in the compiler and dune will also help with removing incompatibilities in the underlying build model.
2 Likes
Absolutely nothing.
I’m not a lawyer, but I study open source licenses “recreationally”, and I can tell you with a high degree of certainty that the licensing of your build tools has no effect on the licensing of the output.
If packages built with Guix linked against Guix GPL code (or any GPL code), then the terms of the license would kick in, but Guix merely automates the deployment process. In terms of using a GPL project, it’s really about what you do with the project’s code, not the compiled artifact. Dynalibs are the exception, but tt’s not even 100% clear if dynamic linking triggers the GPL. The FSF actually intends it to do that, but it’s never been tested in court and there are some legal arguments that this is impossible to control with a license, since the dynamically linked GPL library can be (and often is) distributed independently from software which links against it.
Unless a build tool is doing something very odd, (or it has a very odd, non-GPL license), the licensing of the tool should have no impact whatsoever on the the licensing of the output. As @yawaramin points out, GNU Make is under GPL—and so is GCC, Ansible, and any number of other build/deployment tools.
4 Likes