Hi, it is great that Hackage 2 finally was deployed in production. :-)
How often does Hackage 2 update/pull distro data?
Hackage 1 had a cronjob I believe which ran every few hours I think.
But the new Hackage does not seem to pull often/regularly.
For Fedora I updated the data on 18 Sept and
Not really complaining :) but one of the things I had been looking forward
to with Hackage2 was the display of reverse-dependencies, but I gather it
was disabled for now (because it loads the server too much when updating
the data iirc?).
I was thinking perhaps a compromise would be to show only
For Hacakge 2, the distro ecosystem hasn't had quite as much tooling put
into it as, say, documentation, and it has changed a little bit from
Hackage 1. Previously, there was a cron job that, among tasks like updating
documentation, also downloaded distro info and ran
Hi Matt, thanks for your detailed mail.
On 14 October 2013 17:04, Matthew Gruen wikigraceno...@gmail.com wrote:
Distro maintainers can upload distro information directly to Hackage
(either manually, using a form, or programmatically using something like
curl). It is currently not exposed or
So you're saying we need to add a db proper to hackage2 server, like SQLite
or Postgres so as to make it more performant for interesting features?
What's needed to do that?
On Monday, October 14, 2013, Matthew Gruen wrote:
Hey, thanks for taking an interest in this. There is kind of a
So you're saying we need to add a db proper to hackage2 server, like SQLite
or Postgres so as to make it more performant for interesting features?
What's needed to do that?
On Monday, October 14, 2013, Matthew Gruen wrote:
Hey, thanks for taking an interest in this. There is kind of a
On Mon, 2013-10-14 at 12:18 -0400, Carter Schonwald wrote:
So you're saying we need to add a db proper to hackage2 server, like SQLite
or Postgres so as to make it more performant for interesting features?
What's needed to do that?
I don't think that's needed at all.
What we need is to look
It seems to me that all we really need is a list of all first
generation revdeps on a given package (any version), each specified
maybe as (in pseudodata):
type VersionRange = (Version,Version)
type RevDep = (PackageName,[VersionRange])
RevDeps = [RevDep] (alt M.Map PackageName [VersionRange])