69 lines
3.5 KiB
Markdown
69 lines
3.5 KiB
Markdown
I'm announcing a new, experimental field in the
|
|
[`build-constraints.yaml` file for Stackage](https://github.com/fpco/stackage/blob/1be82f516d5c3c4f276c8119bbae018034a42b25/build-constraints.yaml#L3979). For
|
|
those not familiar with Hackage revisions, let me give a quick rundown
|
|
of how things work:
|
|
|
|
* When you upload a package to Hackage, your tarball includes a .cabal
|
|
file
|
|
* That .cabal file gets included in the index tarball containing all
|
|
.cabal files
|
|
* From the Hackage website, package maintainers and Hackage Trustees
|
|
are able to edit some metadata about a package, like its dependency
|
|
bounds
|
|
* When such an edit takes place, a new .cabal file is added at the end
|
|
of the index tarball with the updated content
|
|
* It is the responsibility of tooling (like cabal, Stack, and the
|
|
Stackage build tools) to—when extracting a package's
|
|
tarball—replace the original .cabal file with the correct
|
|
version, usually the newest version available
|
|
|
|
When a Stackage build runs, until now it would always take the most
|
|
recent revision of a .cabal file and use that for bounds checking (and
|
|
other activities). Then, when creating a snapshot, it would include a
|
|
hash of the revision of the .cabal file it used. That hash is in turn
|
|
used by Stack to ensure that—when building a package from a
|
|
snapshot—it uses the same revision for reproducibility.
|
|
|
|
(Sound complicated? It kind of is.)
|
|
|
|
OK, all that said: what's the problem? Well, there are some
|
|
disagreements in certain cases about whether a revision to a package's
|
|
.cabal file should have occurred. An unwanted revision can create
|
|
undesired work for the package author. After this situation arose a
|
|
few times, I discussed with some involved parties, and came up with
|
|
the `no-revisions` field. Its purpose is really simple:
|
|
|
|
> When the Stackage build tool is choosing which .cabal file revision
|
|
> to use, if a package is present in the `no-revisions` list, then the
|
|
> original revision is used. Otherwise, the newest revision is used.
|
|
|
|
__UPDATE__ Someone pointed out that this "unwanted work" description
|
|
was pretty vague. To clarify, here's an example situation:
|
|
|
|
1. Package author Alice uploads package `foo`, and depends on `bar >=
|
|
2.3` (with no upper bounds). The latest version of `bar` on Hackage
|
|
is 2.3.
|
|
2. Hackage Trustee Bob adds an upper so that, now, `foo` depends on
|
|
`bar >= 2.3 && < 2.4`
|
|
3. Package author Charlie uploads `bar-2.4` to Hackage.
|
|
4. Alice checks on her Git repo and sees that the current `foo` code
|
|
is compatible with `bar-2.4`, so does nothing.
|
|
5. Meanwhile, Stackage discovers the upper bounds and files a bug
|
|
report for Alice to remove the upper bound (that she's not aware
|
|
of).
|
|
6. Alice needs to log in to Hackage and remove the upper bound (or at
|
|
least relax it).
|
|
7. Alternatively, with `no-revisions` in place, Alice could initially
|
|
put `foo` in the `no-revisions` list, and then Bob's changes would
|
|
be ignored completely by Stackage.
|
|
|
|
This is an opt-in field, so people who want the current behavior need
|
|
not do anything. This change will transparently work for Stack, since
|
|
it will simply respect the hash of the .cabal file. And since there
|
|
may be some negative ramifications of this change I haven't
|
|
considered, I'm calling this feature experimental and asking for
|
|
feedback if this causing anyone some issues.
|
|
|
|
Hopefully this change will let people who are using the Stack and
|
|
Stackage toolchain work with less interference, with less friction
|
|
occurring with Hackage Trustees making version bounds modifications.
|