Add package dependencies to the repo

[ikskuh]

This is required for more complex packages that depend on each other. My proposal is to do the following format change:

{
  "dependencies": {
    "${import name 1}": "${package name 1}",
    "${import name 2}": "${package name 2}"
  }
}

This allows package managers to create a correct DAG out of the packages and build a correct std.build.Pkg structure. Import name is the name that needs to get passed to @import(…), package name is the file name in the repository without the file extension.

Example:

{
  "author": "truemedian",
  "description": "A WebSocket 1.3 library for Zig",
  "git": "https://github.com/truemedian/wz",
  "root_file": "/src/main.zig",
  "dependencies": {
    "hzzp": "hzzp"
  },
  "tags": [
    "networking"
  ]
}

[zenith391]

My proposal is a bit unusual but here is what i propose: in a case where a package depends on another package but not its implementation (for example it might depend on a windowing package, but it might be a glfw or an x11 package), there should be a way for the user to choose which to use. Maybe for those case the dependency package name might be null, for example:

{
  "author": "zenith391",
  "description": "OpenGL module for Didot",
  "git": "https://github.com/zenith391/didot",
  "root_file": "/didot-opengl/graphics.zig",
  "dependencies": {
    "didot-window": null
  },
  "tags": [
    "game",
    "graphics"
  ]
}

When installing that package, the package manager should so something like prompt the user to select a package to install, and the user could type didot-x11, didot-glfw or any other windowing package he wants.

[ikskuh]

Counter-proposal to the comment by @zenith391:

{
  "dependencies": {
    "didot-window": [ "didot-x11", "didot-glfw" ]
  }
}

Which would allow a package manager to also prompt the user which package to install, but also list available and checked options. Note that this should not be an enforcement, but a hint. You should be able to override the selection anyways

[zenith391]

As it seems people agreed on it, shouldn't this issue start getting implemented?

[ikskuh]

As it seems people agreed on it, shouldn't this issue start getting implemented?

True! If you have the time, go ahead, implement it and make a PR! I will happily click merge!

[jiacai2050]

It seems that current design doesn’t consider versions, which is important for reproducible build

[ikskuh]

Yes, but i refuse to do version tracking before Zig 1.0.0, as i consider that wasted energy, as your Zig code might break tomorrow anyways.