Purpose for this repo?

[chreekat]

I only see one potential use case for this repo, but it doesn't seem to be used for it. Therefore I wonder if there are other use cases for this repo?

The one (unused) use case I know about

From clues gleaned from the curator README, it sounds like the curator workflow was designed such that curators could "edit constraints.yaml to make tweaks to the build plan".

If curators did modify constraints.yaml, it would make sense to record the final product, which is what I suppose this repo is for.

However, currently curation is automated, and there is no manual gap between generating constraints.yaml and moving immediately to generating snapshot.yaml (via snapshot-incomplete.yaml):

docker run $ARGS_PREBUILD $IMAGE /bin/bash -c \
    "curator constraints --target $TARGET && \
     curator snapshot-incomplete --target $TARGET && \
     curator snapshot"

Thus I wonder if we still need to write constraints.yaml to this repo. Does anybody else use it for anything? Do curators do anything interesting with constraints.yaml manually?

[chreekat]

I should note that constraints.yaml is fully reproducible from build-constraints.yaml , given a fixed version of curator.

[chreekat]

I'm not sure this is a complete answer, but I have discovered that the unpack subcommand requires both a snapshot.yaml and constraints.yaml. From the constrains, it pulls (flags, skipBuild, test, bench, haddock): build flags, and whether or not to build the package and its components (and whether or not to expect failure of the latter).

All this information gets written to the stack.yaml used by curator to build the snapshot, but it's not present in snapshot.yaml.

[juhp]

Yea, I think we need to look over this carefully and slowly - and I suspect it may be required indeed.