WIP/RFC: LTS build constraints

[bergmark]

Warning for ugly code.

Requires: commercialhaskell/curator#25

From that PR:

I think this would simplify the LTS workflow as we can handle LTS like nightly. Maintainers can file PRs instead of curators having to make manual changes to the intermediary files.

This is a first attempt to combine the latest nightly snapshot with the latest build-constraints.yaml to generate a lts-build-consttraints.yaml with major version bounds based on versions in nightly. Essentially we treat every version in the snapshot as ^>= v and intersect that with what's in build-constraints.

lts-build-constraints.yaml was generated using this new binary, so you can check it out to see what the new files would look like. I chose to not parse as actual yaml, it simplified things since I wanted to keep all formatting intact. I could probably use HsYAML for that but it seemed like a lot of extra work

[Vlix]

Isn't this just a suboptimal Data.Text.span?

[Vlix]

Data.Text.stripPrefix?

[bergmark]

$ ./check-lts 22.1
$ commenter diff-snapshot ../stackage-snapshots/lts/22/0.yaml snapshot.yaml
^ stack-clean-old-0.5 -> 0.5.1
^ streamly-core-0.2.0 -> 0.2.1

[juhp]

One question: shouldn't this (the workflow) use the appropriate lts branch.

Well I suppose the code doesn't need to be branch aware necessarily...

[bergmark]

Hmm I don't think so? We use the branches to trigger docker builds, but the nightly build-constraints is still on master. Are you thinking about maintaining multiple LTSes? If so, we could have lts-22-build-constraints.yaml etc. Are there any other considerations?

[juhp]

I feel the workflows will be cleaner if we separate lts and nightly commits to separate branches if possible

[mihaimaruseac]

I think multiple branches will make it harder to copy chunks from one build-constraints file to another. But I think it would be self-documenting and allowing for multiple LTSes if we have multiple yaml files, one for nightly and one for each LTS that we migrate to this

[juhp]

I still have a hope that when we come to make lts-23 we can just fork the master branch and build minor releases off that. That still seems the most clean and consistent workflow to me.
But let's see :-) It is also possible that using the separate repo for lts-haskell will create less confusion for everyone.

[juhp]

You can tweak the curator hash in build.sh now to pull in your new code.

[juhp]

I think it makes sense to move this to lts-haskell if that is where the constraints will live for now?

We will want to run it in CI anyway.

[juhp]

Where or when does lts-constraints get run or used?

[juhp]

@bergmark I closed this since I believe you implemented most if it in curator and lts-haskell instead, right?

Is the lts-constraints tool still useful?

[juhp]

merged into master at e666743