Fork `basement`? As `baseplate`?

Learn
1

This is a similar story to the memory package (see:

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, and (primary) Hackage maintainer, of basement is Vincent Hanquez;
  • for reasons that Vincent has set out elsewhere (including here, about a year ago), he does not wish to develop basement further or introduce other maintainers;
  • Nicholas Di Prima, another maintainer, has declined further involvement (see here); and
  • Michael Snoyman, the last of the three recorded maintainers, has told me that he does not want to violate Vincent’s wishes. Michael has tried to contact Vincent on my behalf but has not received a reply to date.

As with memory, I think: ‘Surely there is someone better placed than me to look after basement’s future?’ So, I raise this topic. However, I am willing to look after basement.

If I published a fork, I am thinking that baseplate would be a good name (as Hackage would not accept Basement). It has the same sense of ‘something that something else is built upon’.

If I implemented this idea, I would be:
(a) an ‘avoid bitrot’-type of maintainer;
(b) definitely in the market for more skilled co-maintainers; and
(c) at least, a person who could be contacted and could ‘reach out to the community’ if something arose that needed action beyond my own capabilities.

My motivation is partly that Stack 3.7.1 depends on basement, as follows:

image
image1744×1307 345 KB

and basement bitrot is finding its way to issues raised at Stack’s GtiHub repository.

11 Likes
2

In my Stack diagram, all of the following are also ‘Vincent Hanquez’ (sole maintainer) packages:

  • socks : Socks proxy (version 5) implementation
  • pem : Privacy Enhanced Mail (PEM) format reader and writer
  • asn1-parse : Simple monadic parser for ASN1 stream types
  • asn1-encoding : ASN1 data reader and writer in raw form
  • asn1-types : ASN.1 standard types

So, forks would be needed of all of them, to free Stack from its dependency on basement. To explore possibilities, I have raised:

3

I think longterm one should trace out how much of basement and memory are actually used by most dependents – my sense its its really only a small portion of both, which could be fruitfully extracted and maintained as a much slimmer package.

6 Likes
4

This may be a bit of an abrasive opinion, but I think that in this case, it would be reasonable to go against Vincent’s wishes, take over the basement name on Hackage, and publish a fork under it.

It would be a bit of a hostile act, but as it stands, Vincent is effectively holding the package hostage - he won’t accept any contributions, he won’t fix it himself, but he also won’t allow anyone else to publish fixed versions in a way that they can be used as drop-in replacements (because that would require reusing the basement name on Hackage).

This is exactly the kind of situation open source workflows are supposed to avoid; open source licenses are explicitly crafted to allow forks and redistribution of independently modified copies, but in this particular case, the fact that Hackage names are first-come-first-serve, and (by default at least) reserved on a personal title, means that authors can effectively designate their own version as the “blessed” one, and even if everyone else agrees to move to another fork, it won’t change the “blessed” status.

Now, I’m not saying that “dispossessing” Hackage names should be done lightly; but in cases like these, where the original maintainers have clearly stated to not be willing to cooperate in any way, it would be the least evil.

Forking basement under a different name would come with serious issues - basement has over 4000 indirect dependencies, and I suspect that many of them have version bounds along the dependency chain that would require releasing new versions of not just the direct dependencies, but also most of those indirect dependencies. Given the sheer number of those packages, such an effort could take months, maybe years, and in the meantime, anyone who is affected by basement bitrot will have to stick to old GHC versions and outdated versions of many packages. And due to the way dependencies work in Haskell, this could even lock people into outdated versions of packages that don’t depend on basement at all: if, due to these shenanigans, you have to stick with an older GHC release, many newer packages simply won’t work anymore, and that will then propagate to other packages.

Considering some of the quite essential improvements that have happened in the Hackage ecosystem lately (such as moving from cryptonite to crypton, moving towards fixing FilePath, etc.), these aren’t just petty concerns; being unable to use up-to-date packages because of shenanigans like these is a full blown security issue.

10 Likes
5

This feels like a bad precedent to set. Vincent isn’t missing; he explicitly left and said that he didn’t want others taking over his packages. You’re suggesting that we ignore his wishes because it’s inconvenient for us?

5 Likes
6

Seeing as I am working on a total replacement for memory, which is effectively in the same position as basement, I feel as though I have an obligation to make my feelings known. I most certainly would like to name my own library memory, seeing as it isn’t a fork of Vincent’s library, and the only thing stopping me is an abandoned corpse, yet I have accepted that I must settle for the alternative of mem or memalloc.

However, the situation does create significant ire.

It isn’t so much about the package itself, as it is the effective name-squatting that occurs as a result. Vincent has the rights to name his memory library, but I don’t necessarily agree that he should get the rights to that name on hackage in perpetuity. Why should we abide by the wishes of someone who has left the community? Vincent isn’t missing, but he also isn’t coming back, and his packages will continue to rot and pollute the namespace. He made his feelings known, a long time ago.

A compromise might be found in tracking when a package has been effectively terminated eg after some time, and allow the package name to be claimed by a new owner with the requirement of a completely new major version to signify the break in continuity, effectively being a new package under the same name as the old - even if it is eg a fork of that exact library under new ownership. Presumably this would never happen automatically, and would require some sort of name takeover request.

The alternative is to imagine yet 10 years from now still, a library that hasn’t built in a decade, still taking up a prime name slot, because of a ghost. Haskell is already burdened with legacy issues, must we continue to add to them?

8 Likes
7

This is hardly the first time this situation has happened. Consider the xml library. It hasn’t been updated in over 10 years. Does someone deserve to take it over? I don’t think so.

To me the only reasonable solution is to allow namespacing packages by the maintainer’s name. Then we could have @vincent/memory and @apotheca/memory without issue.

11 Likes
8

That is exactly what he’s suggesting and I agree with him. You don’t try to replace things from the ground up (with basement, foundation, memory etc.), get people to depend on your packages, then have a burnout / change of heart and leave, while explicitly forbidding people from taking over maintenance to smooth out transitioning out of the resulting mess. He chose “violence” first, sorry not sorry.

Not to mention that this is an interesting loophole that completely invalidates the “package takeover” process. Looks like it’s enough for an individual to publicly mention that he wishes nobody takes over their packages, then disappear forever and now package takeover process no longer can be applied?

9 Likes
9

Counterpoint - lack of updates does not indicate abandonment, it may indicate stability. memory and basement are both in need of maintenance to remain buildable, and both have been actively declared as abandoned by their author so I hardly consider them to be in the same situation.

On the other hand I do find the notion of per-author namepacing to be worth considering as an alternative to my own proposition, which is more of a “well what if” to serve as an alternative to doing nothing, than it is a seriously thought-out opinion. I’m mostly being mindful of the ever-growing load on indexing hackage, and on discoverability, and on how I don’t want to be doing nothing about the problem.

1 Like
10

Another point in favour of namespacing: If the package is not in a stackage snapshot, stack allows to explicitly define a repo URL in stack.yaml which is effectively a namespace, isn’t it?

How do other language communities handle package name uniqueness?
A quick and shallow search indicates that e.g. both PyPi and NPM have adopted namespacing, while Rust’s crates.io also suffers from the uniqueness issue but allows for renaming your dependencies.

Who would stop me if I, for each non-taken package name in the English dictionary and hyphenated combinations thereof, published a fork of acme-missiles under that name on Hackage and declare the same intent as Vincent?

11

You would be banned by Hackage admins for clear vandalism. There’s a gray zone, but it’s miles away from that.

3 Likes
12

i read through all the commentary, and this honestly smells to me as somewhat intellectually dishonest.

“oh my package needs updating but you need my permission to use the unique identifier i own? your package manager should just be better and not let someone cause that problem.”

“i don’t want to be responsible for supply chain attacks if i give someone else the commit bit. also, there shouldn’t be trustees at all who would take this responsibility.”

the whole thing is more FUD and aesthetic theorycraft than practical concerns.

definitely agree this is a package takeover loophole. Package versioning exists and is the solution to his problem. Future version could easily have different maintainers etc - his older versions are still sitting there unscathed by this would-be development.

6 Likes
13

ehh..well what if 1000s of packages relied on it transitively. And something happened (GHC evolution) that broke xml and now it needs some elbow grease. Now vanilla cabal just doesn’t work (and will never work ever again) for a huge part of the ecosystem. Everyone indirectly touching xml must now muck around with cabal.project or a Nix overlay or whatever stack uses for this sort of thing.

So then let’s say the maintainer is contacted and they say “nah I’m not gonna update it. nah I’m not gonna accept any PRs and push updates to Hackage. nah I’m not gonna hand over ownership or even allow someone else to have the commit/update bit in addition to me.”

then YES - that’s takeover time. xml is a good example here because it, like basement and memory, is a core building block other projects may stand on.

Namespacing is cool, but I don’t see how it would be functionally much different here than the whole “fork and rename” approach. The same toil would result - unless I’m missing smth.

2 Likes
14

Each functioning state has ways to overrule the rights of an individual when the welfare of the society is at stake.

E.g. if I owned a large forest in the middle of Germany and the state wanted to build new powerlines from North to South and needed them go through my forest, I could resist to sell, but eventually courts would rule that I have to give up parts of my property that the state needs.

I find it ridiculous that we allow an individual to “own” a name on Hackage for the sole purpose of depriving the community of its use or to pickle a deceased package so that their great works can be admired undefiled for all eternity by posteriority.

A package that has 100s or 1000s of dependents isn’t someones toy project anymore, but a vital resource of the community, and if the author has abandoned it I see no reason why the community should not be allowed to maintain it for the common good.

We are missing a court that decides on such cases, though, and I don’t think there could be a simple rule. Difficult takeovers need to be decided on a case to case basis, balancing the rights of the individual with the needs of the community. And the judges need to be appointed in a transparent way.

22 Likes
15

I don’t understand why it is problematic to use a different name. If people actively depend on it, why wouldn’t they be able to change one name in their cabal files?

I was thinking that there could be a kind of petition system to testify that a package is a vital resource of the community, but I don’t see how signing it would be less work than just changing the dependency. We could simply write a script which automatically submits Hackage revisions to all your packages (I’m volunteering to write it).

Edit: admittedly that only solves half the problem even if it was possible (you’d also need apply the change in your repo). Still, having a script to make this change in a list of git repos and releasing a patch-level updates does not sound like a herculean task. And it has the added benefit of also being useful in other situations where you want to switch to a drop-in replacement package.

5 Likes
16

Revisions can’t change a dependency, this problem is not solvable with revisions.

2 Likes
17

It is not much harder to fork a package under a new name than to take over an existing one. In some ways easier in fact. Basement was a bad package with a bad design, and I do not think it should be forked. Writing a better package with a better name will serve the ecosystem much more.

As a whole, I believe it is better to err on the side of protecting maintainer rights than overriding them for convenience. Once such rights are diminished or abrogated, it is hard to swing the pendulum back the other way.

15 Likes
18

basement2 it is then

19

Just to specify here. Hackage has a criterion that packages are intended to be useful for others. This implicitly bans namespace-squatting, and we have precedent for enforcing it. If someone uploads a bogus package just to claim a name, they have broken a hackage rule, and the admins are in their rights to crack down.

4 Likes
20

Imagine that I declare that bytestring is no longer updated and refuse to pass it to any other maintainer. How would you approach a migration to a fork with a different name, bytestring2? Whoever switches to it (presumably for the sake of support of a new GHC) immediately breaks everyone downstream, because ByteString from bytestring and bytestring2 are incompatible.

We had this very issue with cryptonite / crypton, but on smaller scale, because not that many types were exported out of it. But basement would be a huge challenge.

14 Likes