Possibility of removing packages from Hackage

[jonkri]

I am a little unhappy about that fact that some deprecated packages that I wrote way back are shown on the new Hackage when I search for "pontarius":

http://hackage.haskell.org/packages/search?terms=pontarius

The packages also show up on http://hackage.haskell.org/packages/ (not even being marked as deprecated).

I'd really like for authors to be able to remove packages from Hackage completely.

[dcoutts]

We're not going to remove packages but we can certainly make deprecated packages not show up so much, or be clearly marked as deprecated. Certainly they should be clearly marked (e.g. could use strikethrough or different colour, plus the deprecated tag). And we should do that more consistently.

It's open for discussion to what degree packages should not appear, and if that needs to be configurable.

[jonkri]

Hi!

1. Why can we can not remove packages?
2. What is the benefit of displaying deprecated packages?

Thanks!

[dcoutts]

1. it's a cardinal rule of package distribution that package tarball checksums never change (including not disappearing)
2. people may want to find them. Of course we should not promote them, and there may be times when it's best not to list them, but they should still be there if someone is specifically looking for it.

[jonkri]

I see.

How about this:

1. A checkbox under the input field on http://hackage.haskell.org/packages/search, "Show deprecated packages", disabled by default? When deprecated packages are included, they are labelled as such.
2. Deprecated packages does not show up in the http://hackage.haskell.org/packages/ list at all.

[sol]

I agree that tarballs should not be removed. But other than that I think I as a package author should have the right and means to unpublish my own packages.

My preferred solution would be that after deprecating a package the tarball and package page (the one at http://hackage.haskell.org/package/<packagename>) stay intact. But I would not want the package to appear anywhere else (esp. not under http://hackage.haskell.org/user/<username>).

[hvr]

@sol it appears only under http://hackage.haskell.org/user/<username> if you're in its maintainer-group... so you'd simply have to leave the maintainer group of that package

@sol also, what about http://hackage.haskell.org/packages/deprecated ? would you want that index to be destroyed as well?

[sol]

@hvr Good point regarding the maintainer-group.

Regarding the list of "All deprecated packages", I see how this can be interesting, but I'm still puzzled in which scenarios this is useful.

[andreasabel]

If you are moving to a new house, you can keep everything for a while, but after some years, you have to start thinking how to sort out some things that just sit there collecting dust.

I think for hackage the time has come where we have to think about procedures for spring cleaning.
Packages that haven't been buildable for years and are abandoned by the maintainers and forgotten by the world should be moved to an attic space rather that continue to sit in the main hackage directory. Why? Is disk space a problem? Well, no, most can still afford 500MB for the package index (as of Nov 2018), but:

• Old, abandoned packages are squatting nice package names.
• The Haskell developer looking for a library for a certain purpose has to search through a pile of trash to find the gem.
• Having no quality control at all on the central package server does not shine a good light on the Haskell community.

I think packages that have not compiled for many years should lose their right to remain on hackage. They can be moved to some attic space where they can remain for archeological purposes or wait for their resurrection.
Weeding out the dead packages would be a first step to a saner hackage (one could think of further quality ensurance mechanisms later, like reviewing or ranking by reverse dependencies...).

[Maybe I should open a new issue for my proposal?!]

[gbaz]

I think the need for a clean presentation should be covered by #680

I have that assigned to me but if someone wants to take it over, it would be welcome.

In short -- we could establish standard "filter" criteria that would screen out packages that hadn't been uploaded in however long, or that didn't build with newer ghcs, etc. This can all be done by augmenting our current table display with some additional javascript.

[kolmodin]

If you are moving to a new house, you can keep everything for a while, but after some years, you have to start thinking how to sort out some things that just sit there collecting dust.

I think for hackage the time has come where we have to think about procedures for spring cleaning.
Packages that haven't been buildable for years and are abandoned by the maintainers and forgotten by the world should be moved to an attic space rather that continue to sit in the main hackage directory. Why? Is disk space a problem? Well, no, most can still afford 500MB for the package index (as of Nov 2018), but:

• Old, abandoned packages are squatting nice package names.
• The Haskell developer looking for a library for a certain purpose has to search through a pile of trash to find the gem.
• Having no quality control at all on the central package server does not shine a good light on the Haskell community.

I think packages that have not compiled for many years should lose their right to remain on hackage. They can be moved to some attic space where they can remain for archeological purposes or wait for their resurrection.
Weeding out the dead packages would be a first step to a saner hackage (one could think of further quality ensurance mechanisms later, like reviewing or ranking by reverse dependencies...).

[Maybe I should open a new issue for my proposal?!]

I disagree that we should remove packages.

• Most package names are not taken, just pick a new one. When packages are forked people come up with new names, it's not an issue. What is a nice package name anyway? Are attoparsec and criterion bad names? Just name your package whatever you want, if it's a good package it'll be used :)
• If discovery of good packages is hard then that's a problem thats bigger than having to look at some old packages. Search should be improved rather than pruning the package database. That would solve visibility of good packages, demote unpopular packages (broken, old or just plain bad).
• A package cannot be resurrected, as you suggest, if its package name has been taken.

It's seems that at the core of this issue is the problem of finding good packages, not that we also have bad packages. IMO we should spend time on promoting good packages (with some package ranking) rather than spending time on completely removing a small set of packages and keep the poor search we have.
Spring cleaning is after all just a ranking where you highlight the useful stuff and demote things you think will be less useful in the future.

[andreasabel]

@kolmodin

we should spend time on promoting good packages

I agree, but this is orthogonal to the issue of name squatting.

* Most package names are not taken, just pick a new one. When packages are forked people come up with new names, it's not an issue. What is a nice package name anyway? Are attoparsec and criterion bad names? Just name your package whatever you want, if it's a good package it'll be used :)

Well, I agree there is an potentially infinite amount of available identifiers, but still authors prefer "nice" and "canonical" names, and these are a valuable resource. E.g., I also named my package cabal-clean even though it implements a limited tool, and now I am sitting on this brand, and I will discovered early when folks search for "cabal clean" or similar.

* A package cannot be resurrected, as you suggest, if its package name has been taken.

There could be a way of contextual name resolution to overcome this eternal binding of a name to a certain package. For each point in time, we could have a mapping from names to packages. An uploaded package will resolve its dependencies according to its upload context. This way, old packages can point to the correct package even if its name has been assigned to a new package in the present.
(This is a bit how natural language works: words have meaning depending on a context, and so can be filled with new meaning. The correct meaning can still be determined from the context in which they appear. Of course, in real history we typically have lost most of past contexts, but in the digital world, we can preserve these contexts forever, in the same way as we preserve the packages forever.)

You could even point to a shadowed package by providing its context explicitly with the name, so we could have e.g. collections@2013 if you wanted https://hackage.haskell.org/package/collections that should have been garbage-collected already.