Stackage’s no-revisions (experimental) field

综合编程 2017-04-27

I'm announcing a new, experimental field in the
file for Stackage

. 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.

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.

责编内容by:Michael Snoyman's blog (源链)。感谢您的支持!


UTC is Enough for Everyone, Right? Since the dawn of time Years ago, I worked with a friend who had...
Breaking Down Binary Ninja’s Low Level IL Hi, I’m Josh. I recently joined the team at Trail of Bits, and I’ve been an eva...
Understanding the npm dependency model Currently, npm is the package manager for the frontend world. Sure, there...
Speak the same language They’re just names at this point. On a sheet of paper. The iceberg ...
Single Sign-On authentication – the bug that lets ... Logon security company Duo recently found a rather worrying flaw in its ow...