Let's remove acme-everything from Hackage

While there’s no strict quality requirements or guarantees on things published in Hackage, there’s one package that sticks out, littering reverse dependencies list of most packages: acme-everything: Install everything.

It’s just noise. If someone wants to maintain that I think github is the proper place for that, having it in Hackage is actively harmful.

Is there anyone who would be against removing it?

6 Likes

I’d support this proposal. acme-everything is cute, but it doesn’t belong on Hackage.

Of course, IIRC, Hackage has a no-removals policy… but acme-everything is such a bizarre edge-case that it seems reasonable to treat it differently.

2 Likes

I take the point. However, if tooling is vulnerable to this kind of “exploit” then it’s also worth seeing if we can fix the tooling, for example by applying criteria for filtering what’s shown on reverse dependency search.

6 Likes

I’d find it acceptable to implement a limit on how many dependencies a package may have to be considered for inclusion to reverse dependencies list. I wouldn’t mind acme-everything in that case.

Probably more interesting is the number of downloads. acme-everything has had 3 in 30 days.

Current policy is clear:

Packages cannot be deleted, so you should consider uploading new package versions as package candidates and testing before publishing to the main index.

There has been problems with the package already (#390, #415), so filing a ticket in hackage-server issue tracker might lead to something.

1 Like

01-index.tar.gz is append-only, we cannot ever remove a Cabal file. We can remove the contents of the package (it happens sometimes, for instance, due to copyright violations), but reverse dependecies are calculated from Cabal metadata only. We can also make a revision (e. g., base < 0), but again this will not affect reverse dependencies AFAICT. I think the best is to adapt revdeps algorithms to ignore acme-everything as suggested by @kaol above, in Let's remove acme-everything from Hackage - #4 by kaol.

6 Likes

Since it cannot be deleted outright (for now), could it be “hidden” instead, in much the same way that e.g. deleted posts here on Discourse are dealt with? Yes, that also means not being able to reuse the package name…but in this particular case that really shouldn’t be a problem.

It’s actually a very useful package, because it is a stress test of the platform.

4 Likes

And not just the purely technical parts of the system, it seems :wink:

12 Likes

…yes, but right now it’s a stress test without any control over it. One possible solution is keep a separate list of such “interesting” packages somewhere on Hackage e.g. as a simple text file mapping names to codes, like:

https://archive.org/download/citeseerx-csx_citegraph.2017-03-31/citeseerx_checksums.tsv.gz

In this way, those who really do want such packages can provide the corresponding code to directly access them.

In my opinion, none of the messages here give an actual convincing reason on why we should remove this package, even if we could.

3 Likes

I actually find this proposal offensive.

Packages are owned by the package author. They provide a license and they own it.

Hackage is not a place where we democratically decide which packages we find useful.

Unless a package breaks some hackage policy, it’s not to be purged in any way.

You’re free to create a community index of packages that you find useful, etc.

4 Likes

Ok, I’ll bite. Please tell, in your words, what’s the purpose of the reverse dependencies feature of Hackage?

What we need is this: Expose json variant of `/package/:package/reverse` · Issue #1230 · haskell/hackage-server · GitHub

Then you can do trivial post processing in scripts and other websites.

1 Like

No, please answer my question. What’s your thoughts on what purpose does the field have? What kind of impression do yout think it makes to have packages like that in there?

The purpose is to return accurate information of reverse dependencies, not interpret them or do postprocessing for specific use cases. You can do that yourself (given the endpoint above is exposed).

Personally, I think reverse dependencies is pretty helpful when looking at a package you’ve never seen before, (along with downloads) to determine the likelihood it will remain maintained. High downloads with a low number of reverse dependencies means that if the maintainer disappears, the package might still be allowed to die because the few reverse deps may move to something else. A high number of reverse deps increases the chance someone would step up and maintain it.

3 Likes

wym? Find packages that build on a package. That’s inherently useful.

I’ll throw in my $0.02: IIUC, the deal with Hackage, much in the spirit of free software, is “as-is” - anyone can upload software, but it’s up to you, the “user”, to decide what to do with it, which packages to use, and whether they meet your desired quality standards. If you don’t like acme-everything, don’t use it.

Reverse dependency tracking, then, is a secondary feature of Hackage - useful, yes, popular, also yes, but still secondary. The thing that is arguably broken is not the fact that acme-everything exists, or that it lives on Hackage, but the workflows and tools that break because of it. This is like building slower airplanes because the departure board at the airport is broken.

So what I would like to know is what exactly the problem is that removing acme-everything would solve. I suspect the problem here is that Hackage’s reverse dependency feature does not capture the information you would like: it gives you “literally any package on Hackage that depends on this package”, whereas what you want is “any serious package that depends on this package”, for some definition of “serious” (“something that isn’t a joke”, “something that people use for real-world software”, “something that’s mature”, “something that meets a certain quality standard”, etc.). But Hackage can’t do that, because that would require a decision on what “serious” should mean, and that’s not what Hackage is - it’s not a curated list of high-quality non-joke packages, it has always been low-threshold, on purpose, leaving the curating to other means.

On a more political note: requests like these, to me, highlight a certain friction in the open-source ecosystem at large. On one side, there’s the “scratch-an-itch” demographic, developers who share code they wrote with an “as-is” understanding - “use it as you wish, but if it’s broken, that’s your problem”. On the other side, we have a heavily commercialized software industry that has developed a habit of using open-source packages with an implied assumption of maintainership and accountability - “I’m using this code for a mission-critical system, so that means someone must take responsibility for it” (but few are willing to actually pay anyone for that responsibility). And this request here smells a bit of the latter.

7 Likes