input-output-hk / foliage

🌿 Foliage is a tool to create custom Haskell package repositories, in a fully reproducible way.
MIT License
42 stars 9 forks source link

Add information about revisions to `packages.json` #44

Open michaelpj opened 1 year ago

michaelpj commented 1 year ago

At the moment there's a timestamp field, but that's the time the package version was added. It would be nice to know about revisions. I can see a few possible designs here:

The reason I care is that the CHaP CI diffs the metadata to tell when packages have changed, so it knows what to build. At the moment it can only notice new package additions because revisions don't affect packages.json. Making them change it in any way would suffice for my purposes!

michaelpj commented 1 year ago

See https://github.com/input-output-hk/cardano-haskell-packages/issues/170

andreabedini commented 1 year ago

My worry here is that we are basically building a toml to json converter :P I am not against this but I wonder if the CI could look at _sources?

Edit: This is slow but seems to do get you there already.

$ nix shell nixpkgs#yq
$ for m in $(find _sources/ -name meta.toml); do IFS=/ read -ra PARTS <<< "$m"; tomlq --arg name ${PARTS[1]} --arg version ${PARTS[2]} '{ "pkg-name": $name, "pkg-version": $version, timestamp: .timestamp, "revisions": [.revisions[]? | .timestamp] }' $m; done
...
{
  "pkg-name": "plutus-core",
  "pkg-version": "1.1.0.0",
  "timestamp": "2022-10-21T00:00:00+00:00",
  "revisions": []
}
{
  "pkg-name": "plutus-core",
  "pkg-version": "1.1.1.0",
  "timestamp": "2022-10-31T00:00:00+00:00",
  "revisions": [
    "2023-02-22T19:09:40+00:00",
    "2023-03-21T14:21:44+00:00"
  ]
}
...

btw, I initially used toml because nix suports it natively, but then it tuned out that nix cannot read toml timestamps :-/ Edit: maybe we can fix that https://github.com/NixOS/nix/pull/8120

michaelpj commented 1 year ago

Well, that was what I was doing originally and then you made the metadata output and I thought I was supposed to do that :p also tomlq looks nice! I can probably work with that indeed.

andreabedini commented 1 year ago

:thinking: I guess one difference is who is using that information. If it's in CI we have the input metadata, so we don't really need anything else. If it's the end consumer (whoever is using cabal) they don't have access to the input metadata anymore, which is why we made package.sjon.