The ^>= operator in .cabal files

[andreabedini]

@hasufell

It breaks an important invariant that package tarballs are self-contained (this matters for distros, tooling, mirrors, scripts, …)

The devil is in the details. The tarball is immutable and self-contained (and cryptographically signed). The hash of ghcup-0.1.19.2 hosted at https://hackage.haskell.org/package/ghcup-0.1.19.2/ghcup-0.1.19.2.tar.gz is

b25a15adaaca30a227ed12560d1d89924d9d3ae17fc5798f20f2f00484866088

and that will not ever change.

The “curation” part is a separate “service” built on top of the regular tarballs. Your use of the word converted is misleading, the tarballs are there. This is an interesting thread about the role of package metadata:

Cabal upload revisions? and some philosphical points

Well think of it like a book. When someone writes a book, they tend to mean the content of the book, the chapters, the introduction, conclusion, etc. If there was a missing entry in the index added, or if the ToC were fixed because the chapter numbering was listed wrongly in it, there’s a sense in which we’d understand that “the book itself is the same”. On the other hand, it makes sense to bind books with a ToC and index, because those are useful tools in the reading of the book itself. Hence,…

@hasufell

the hackage index format is also ad-hoc and “internal” btw

It is (kinda) documented and there are few packages to access it.

What’s ad-hoc in your definition? Is ghcup metadata format ad-hoc?

Techologically speaking, I agree the index format is a bit … “not-fancy”. I invite anyone interested in a re-design to open a thread to discuss. Personally I’d like take some ideas taken from stackage’s pantry. I once tried to define a canonical conversion to git (to subsume a half doznen ad-hoc options you can find on GitHub) but I never managed to finish running it because there are 171k entries in the index and my Python script could not cope

@hasufell

It burns out hackage trustees: this is easy to see from the interaction I’ve had with them, the turnover and the amount of panic my PVP PRs have caused.

Burning out doesn’t seem to be exclusive to trustees, I bet they burn out just like everyone else

@hasufell

It’s a “let it break, then fix it” approach. But the fix is tighter constraints usually and not a code patch that improves compatibility.

What breaks? My definition of breaking is when a package stops to compile. Speculative upper bound prevent that and relaxing them after manual verification is definitely not a "let it break, then fix it” approach.

@hasufell

Hackage revisions can break freeze files that don’t pin the index. This has happened before, when a revision caused tighter upper bounds than necessary.

@andreabedini

(Needless to say: automated testing could make all this easier and less error prone. There have been cases of bad revision but they can be fixed quickly)

@hasufell

There’s no automation about it at all. Everything relies on explicit communication and people doing manual labor.

We furiously agree here. Better tooling and more automation is sorely needed. I can do little but I know I am doing it.