So we're going to really start now this time about Opam's Nick system dependency mechanism.
Ryan, give us going to talk about that.
We already saw a talk by Ryan, and we're curious to see this one, so go ahead, Ryan.
Thank you very much, everyone.
So I'm going to give you a quick talk on Opam's Nick system dependency mechanism.
So if you don't know Opam is the Oklahoma language package manager, and as with many other
languages, you can use Oklahoma packages from Nick's packages or specialized overlay,
but sometimes the packages or package versions you might need might not be included in
that repository or overlay.
You can use a project like Twigs or PAM Nick's to programatically generate Nick's
derivations from an Opam solve for your project and its dependencies.
This is great for deploying a project developed with Opam to a Nick's our system, but it isn't
a great experience for development.
It's quite slow and you need to do an expensive Nick's rebuild every time a dependency
is added or updated.
Can we just use Opam on Nick's systems?
Well, yes, for Oklahoma dependencies, but not trivially for non-Ochemical dependencies.
If you depend on, for example, C libraries, you need to set up a Nick's development environment
using something like Nick's shell or Nick's develop with the system dependencies.
This requires a manual resolution of those dependencies, and the resulting binary will
contain a path in the next store, which isn't part of a garbage collection route.
So the built artifacts will stop working on the next next GC.
I'm saying system dependencies a lot, and what I mean by that is Opam is rather unique for
a language package manager in that supports providing non-Ochemical dependencies as external
dependencies, they're called DepX, DepX.
You can declare, parameterize, by things like an operating system, packages to be installed
by your system package manager.
So this is an example for the GNP project.
This is like a C library for numerical computation.
You can see here, on Nick's sauce, we depend upon the GNP package, but in DepX, for example,
it's named LibGempDev.
So when using a project that depends upon GNP in Oklahoma on a DepX system, Opam will invoke
up-get install LibGempDev, the equivalent in a Nick's system would be a Nick's and
the equivalent in the GNP, but this will only add binaries to the path.
It won't set up flags that we need for development such as linking flags.
So to provide Nick's system dependencies with Opam, we overhauled its system dependency mechanism
in order to support this.
So Opam gets the lists of DepX for the current switch, which is like a virtual environment,
and creates a Nick's derivation file, they'll look something like this.
You can see here we have the inputs to the derivation, which are the DepX from the Opam repository.
And then the build phase, which is the only phase, builds an environment file that Opam
can read, which sets up the environment variables, used inside the derivation.
And you can see there's a list of variables which are excluded or appended to, instead
of a normal export, and this is from the Nick's developer source code actually.
This is basically how Nick's shell next to help work under the hood, but we're using the
Okamil Package Manager to manage the environment.
Can I get rid of that little, yeah, it's all right.
So basically the resultant environment file is actually a RIT in the Nick's store, the
Nick's GC thing, so it won't be garbage collected as long as that file exists.
So that means your build artifacts will continue to work until you actually remove the switch,
which is quite neat.
Another neat aspect is it won't interact with your system environment, like the Opam,
DepX mechanism with on another system, such as Debian, when you do that app install,
blah, that changes your whole system.
So this could be useful even on the next system.
So before if you return install packages that depended upon ConfGMP, like the Let's Encrypts
Library for provisioning till last year to forgets, you would get this linking error.
But now you get prompted, do you want to run the Nick's build, and it will run a Nick's build
upon this m.nix file, which is what I showed you earlier, and it will generate a Nick's
own file.
Those are different names, it's a little confusing, but that's actually the environment
file, the Opam will read, and then you can see the subsequent install works seamlessly.
And without this mechanism, you would have to manually get all the system dependencies
you might need.
Thank you.
Let me know if you have any questions, grab me at the end, or something.
Thank you very much.