David Thomas wrote:

...

We could even set up NotOnHackage: a "package" repository just like Hackage, except the packages are just documentation on why there is no such package. Implementation-wise it's just a wiki; but the idea is about how to organize the wiki. NotOnHackage should be organized and searchable similar to Hackage itself, so that people can look there when nothing looks promising on Hackage.

Couldn't this be actually on hackage, so one search turns up what you want?

Yes. There is no reason to put up a second Hackage for that one. Without changing anything in the current system, packages can just update their categories, so that they will be displayed below "Defunct" or something like that. This is fine, as only the categories of the latest version are significant. If you think this is a good idea, I will start with some of my packages. =) Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad.

I think it needs to be both places. I know when I'm searching, I often just go to google with "site:hackage.haskell.org inurl:latest" I would be likely to miss it if it were just in the cabal file (although in the modules it could be as simple as a note saying "this is defunct - view the main page for an explanation of why). Alternatively, if there is much reasoning specific to a particular module it could certainly go there, while the cabal gets the overview... On Fri, Jan 25, 2013 at 3:23 PM, wren ng thornton wrote:

On 1/24/13 1:40 AM, Ertugrul Söylemez wrote:

...

David Thomas wrote:

We could even set up NotOnHackage: a "package" repository just like

...

...

Hackage, except the packages are just documentation on why there is no such package. Implementation-wise it's just a wiki; but the idea is about how to organize the wiki. NotOnHackage should be organized and searchable similar to Hackage itself, so that people can look there when nothing looks promising on Hackage.

Couldn't this be actually on hackage, so one search turns up what you want?

Yes. There is no reason to put up a second Hackage for that one. Without changing anything in the current system, packages can just update their categories, so that they will be displayed below "Defunct" or something like that. This is fine, as only the categories of the latest version are significant.

If you think this is a good idea, I will start with some of my packages. =)

We've had package deprecation for a while, so the big trick IMO is the documentation. Good descriptions of why the package is defunct and suggestions on how people can do things better.

If we're going to do it on Hackage itself, I think the big question is one of style: should the documentation be all in the cabal file (i.e., on the package description page, with no modules in the package); or should we put the documentation into modules?

-- Live well, ~wren

______________________________**_________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe

wren ng thornton wrote:

...

Yes. There is no reason to put up a second Hackage for that one. Without changing anything in the current system, packages can just update their categories, so that they will be displayed below "Defunct" or something like that. This is fine, as only the categories of the latest version are significant.

If you think this is a good idea, I will start with some of my packages. =)

We've had package deprecation for a while, so the big trick IMO is the documentation. Good descriptions of why the package is defunct and suggestions on how people can do things better.

If we're going to do it on Hackage itself, I think the big question is one of style: should the documentation be all in the cabal file (i.e., on the package description page, with no modules in the package); or should we put the documentation into modules?

I think the package should be included in full, and the package documentation should clarify why the package shouldn't be used. The idea is that people can still download the code and see how not to do it. It also helps to keep legacy code working, because "bad idea" doesn't necessarily mean, "you could die if you use this". You might go as far as implementing special support for this in the cabal-install tool in the form of a flag like --allow-defunct. Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad.