This is a similar story to the memory package (see: Fork `memory`? As `memoria` or `Memory`? ; and Improving `memory` with better abstractions . basement is a direct dependency of memory). That is, I understand that there is a need to fork the basement package. It arises because: the originator,…

Still not solves the “someone rage-quit while squatting on @hackage/ namespace” problem which is a policy problem, not a technical one. Personally, I’m okay with fork-and-rename and the resulting churn. Things happen. What I really want to see here, both as a maintainer of packages and a developer…

Now what constitutes abandoned? In this particular case it is quite clear, as the author was explicit about this. Six months? Two years? Not building with X versions of GHC? What if a maintainer just keeps uploading new revisions, but neglects what people want? What if they take the package in …

[image] Dominik Schrempf: I also dislike that names on Hackage are given away for free, while there is no possibility of taking them back. I mean, an evil actor could reserve a ton of important names without much problems. This was addressed upthread. The minimal criteria on hackage that a pa…

In the age of LLMs, I can just produce a technically-useful library for about any useful name. Usefully trained on the weighted average of all of Hackage. It’s useful because I trained it existing useful stuff. But it was free to make and now I can say I’m done with it but keep the name for free …

[image] turion: I’d be in favour of a tiered system: I like this, but I’m toying in my mind with a slight adjustment: you get a non-prefixed name by default. If I’m the first person to publish a package named acme-missiles, then I get both @philh/acme-missiles and a global acme-missles pointi…

I also think that an option for not getting the global package name by default would be appreciated as there are many work in progress hackage packages that don’t need a spot on the global namespace. I’d include my package under that label.

I do think there are awkward questions around: suppose I depend on a and b, which both depend on x. x gets forked into x2, and a updates to use that but b doesn’t. I say “x is provided by x2 instead”. Are types x2:X.T (visible to me via a) and x:X.T (visible to me via b) the same type? We can’t get…

[image] danidiaz: I would expect x2:X.T and x:X.T not to be the same type. They would only be the same type if a and b were “instantiated” with the same variant of x. So the awkward thing about this is, if my package relies on a and b sharing an X.T type, then a updating to x2 breaks my code …

By way up update, today, my original motivation now looks like this, as the tls universe has significantly reduced its dependency on unmaintained Vincent Hanquez packages: [stack-dot-2026-03-01] If @ApothecaLabs succeeds in replacing memory with a maintained alternative, and crypton could be wean…

I guess you could just copy and paste the basement code into crypton directly if that’s the only issue? Ofc it would be better to do more than that, but that’s a quick and effective way to sever the limb.

Haskell Community

Fork `basement`? As `baseplate`?

Learn

show post in topic

Home
Categories
Guidelines
Terms of Service
Privacy Policy

Powered by Discourse, best viewed with JavaScript enabled