Figuring out dependency DAG

Ecosystem
1

Hey hey,

I’ve been a bit frustrated at how difficult it is to specify dependencies and their versions with dune/opam. I’m prototyping something that will force you to explicitly specify all your direct dependencies (opam or pins) and their versions. It looks something like this (in toml):

[package]
name = "my_lib"
version = "0.1.0"

[ocaml]
ocaml_version = "4.12.0"

# your dependencies go here
[dependencies]
core = "v0.14.1"

Now I’m running into this problem: how to figure out if there’s a dependency DAG that will work and install it? The only method I can think about is to manually create an opam.export file that specifies dependencies and pins and try to import it in a local switch.

1 Like
2

Hi,

I’m curious as to what your TOML format introduces over what’s already supported in .opam files. For instance, the example you gave could be written as:

name: "my_lib"
version: "0.1.0"

depends: [
  "ocaml" {= "4.12.0"}
  "core" {= "v0.14.1"}
]

With this format, opam install --with-test --with-doc . should be sufficient to install the dependencies. (This is the format that opam monorepo uses for its lock files, for instance.)

If your concern with opam files is just the syntax / ergonomics being offered, it still seems best to consider what Opam file you’d like your metadata to be “compiled down” into (since opam files already capture the kinds of queries that can be issued to the opam CLI manually).

1 Like
3

I don’t want to sound like a gatekeeper, but I’m also surprised why anyone would have a problem with specifying dependencies in OPAM. I had experience with multiple packaging tools, and OPAM is no worse than any of them.

If your concern with opam files is just the syntax / orgonomics

Did you mean “oergonomics”? :slight_smile:

1 Like
4

Just want to say that you should look at esy.
This is the default behavior unless you explicitly add a range to your dependency

5

Just fyi, dune already supports specifying all these dependencies: OPAM integration — dune documentation

And if you don’t like either the opam or dune formats, there’s drom, which also uses TOML format: [ANN] drom.0.2.0: OCaml Project Manager, beta release

But I think if the main thing you want to solve is to ‘force you to explicitly specify all your direct dependencies (opam or pins) and their versions’, then you have no choice but to use esy or nix. I mean, unless you want to reimplement package management.

1 Like
6

dune is going to ignore the content of your opam files, so you can’t really enforce anything through opam package files for your project.

7

Interesting, I’ll take a look. Do you know how painful the move to esy would be for a large OCaml repo?

8

The problem with that is that you specify this in dune-project files. Maybe it’s not a problem, but I’m always a bit confused as to how one should arrange a large project that contain many internal libraries with dune and dune-project files. Maybe if I create one dune-project file per library then that’s fine?

As for drom, it creates way too much configuration and boilerplate. I was looking for a cargo-like solution that favors convention over configuration (and hence only uses a few toml files and “guesses” what the different modules are based on file structure).

I’ll look at esy, but does it work with opam repository?

9

Yes, esy can consume packages published on both opam and on npm.

1 Like