While at the Hackathon, Björn, Ross, Ian, myself and others collected some ideas for directions in which Hackage (the web interface primarily, as opposed to cabal-install) should develop. I put everything in this wiki page: http://hackage.haskell.org/trac/hackage/wiki/HackageToDo It's quite rough, but I think it's a good starting point. I suggest we do some more brainstorming and flesh out that page, and then extract a "plan" for how to proceed. Of course the plan shouldn't be single threaded - there will be tasks that can be tackled independently, but there will necessarily be dependencies. For example there are lots of things that can't be done until we have automatic package building of some kind. We should have some milestones, focussed towards getting to a point that the system is usable quickly, and adding the bells & whistles later. First off we have two web interfaces: Ross's and Lemmih's. Ross's lets you upload. In due course having multiple web interfaces is certainly a possibility, but for now we need to focus our limited efforts in one place. I suggest Ross's inteface, being the closest to being usable, is the right place to start. Ross - is it possible to write some simple instructions describing how to set up the web interface on a local machine for development/testing? Cheers, Simon
Simon Marlow
While at the Hackathon, Björn, Ross, Ian, myself and others collected some ideas for directions in which Hackage (the web interface primarily, as opposed to cabal-install) should develop. I put everything in this wiki page:
:)
It's quite rough, but I think it's a good starting point.
I added some ideas about searching / querying the package database. One idea is that I really like the way trac does querying and group-by. Once you build a query, you can also get an RSS feed based on that query. It would be pretty easy, I'd guess, to have Hackage output RSS as well as html.
I suggest we do some more brainstorming and flesh out that page, and then extract a "plan" for how to proceed. Of course the plan shouldn't be single threaded - there will be tasks that can be tackled independently, but there will necessarily be dependencies. For example there are lots of things that can't be done until we have automatic package building of some kind. We should have some milestones, focussed towards getting to a point that the system is usable quickly, and adding the bells & whistles later.
I think that, as far as Hackage (not cabal-install) is concerned, the main usibility points are: 1) getting more packages into it 2) making sure that all the packages build together, and 3) searching By the way, I really like the idea of tags instead of categories. Although categories are simpler to understand and obvious, so perhaps we should have a facet that's "PrimaryCategory" (or leaving the category field alone and adding tags). There is something to be said for picking a "smart" default view for end-users, rather than giving them too many choices. This view is quite nice: http://hackage.haskell.org/packages/archive/pkg-list.html peace, isaac
Isaac Jones wrote:
I added some ideas about searching / querying the package database.
One idea is that I really like the way trac does querying and group-by. Once you build a query, you can also get an RSS feed based on that query. It would be pretty easy, I'd guess, to have Hackage output RSS as well as html.
Yes, nice idea.
I think that, as far as Hackage (not cabal-install) is concerned, the main usibility points are:
1) getting more packages into it 2) making sure that all the packages build together, and 3) searching
Ah yes, there was the idea of freezing a collection of packages that build together too.
By the way, I really like the idea of tags instead of categories. Although categories are simpler to understand and obvious, so perhaps we should have a facet that's "PrimaryCategory" (or leaving the category field alone and adding tags). There is something to be said for picking a "smart" default view for end-users, rather than giving them too many choices. This view is quite nice: http://hackage.haskell.org/packages/archive/pkg-list.html
I think tagging is premature, just having categories with the ability to put a package into multiple categories will be just fine for now, IMO. See my message yesterday on libraries@. Cheers, Simon
Simon Marlow wrote:
Isaac Jones wrote:
I think that, as far as Hackage (not cabal-install) is concerned, the main usibility points are:
1) getting more packages into it 2) making sure that all the packages build together, and 3) searching
Ah yes, there was the idea of freezing a collection of packages that build together too.
One related problem is that .cabal files don't allow you to describe the dependencies well enough. For example, many packages currently in Hackage have fps as a dependency. This is no good with base 2.0, which includes what used to be fps. But removing the fps dep will break building with base 1.0 + fps. Some possible solutions: - Allow boolean expressions not only of versions, but of packages as well. E.g.: Build-depends: base >= 2.0 || (base < 2.0 && fps >= 0.7) - Have one Hackage repository for each Haskell implementation version, where the dependencies make sense together. - Configurations? /Björn
On Thu, Jan 18, 2007 at 02:41:05PM +0100, Björn Bringert wrote:
One related problem is that .cabal files don't allow you to describe the dependencies well enough.
- Configurations?
This is what configurations are designed for. Until we have them I think the best thing is to have the packages in hackage work with the current releases (I think ghc and hugs have pretty much the same libraries; I'm not sure about nhc/yhc/jhc/... off the top of my head). Hopefully before we have an incompatible new hugs/ghc release we'll have a Cabal with configurations. Thanks Ian
participants (5)
-
Björn Bringert -
Ian Lynagh -
Isaac Jones -
Simon Marlow -
Simon Marlow