As long as we take shortcuts through the GPL C bindings the situation will never improve for Windows users.

anyway, it is already pleasure to use hackage and cabal.

1) ability to deprecate (and hide) a project
2) visible indication of the license in the pkg-list.html, better color-coded

i’d say it’s not solely a technical problem.

I think the problem here is that packages that are likely to be tricky for cross-platform scenarios (i.e. do a lot of specialised IO stuff) don’t always have a large enough team with people on a range of platforms.

For example, with my graphviz library, I have no idea whether it works on Windows or Mac; however, as long as dot, neato, etc. are in the $PATH (i.e. so that runInteractiveProcess can find it) I see no reason why it shouldn’t. There might be a better, more cross-platform approach to dealing with external commands, but I don’t know of it.

My previous comments weren’t aimed explicitly at you; it’s just that every now and then I see complaints from people on #haskell, haskell-cafe, etc. that such-and-such library, tool, etc. doesn’t work properly on Windows but rarely do they ever seem to indicate that they are willing to put actions to words and help _make_ it work.

It’s Open Source – no-one *has* to do anything.

However, solid cross-platform support in key libraries is undoubtedly going to help to promote Haskell – a key advantage of Python is that pretty much all of its key libraries work essentially identically across all supported platforms (I understood that we are trying to fail to avoid success here :-)

The download stats say that something like 75% of Haskell Platform downloads are for Windows, so clearly the demand is there for solid support.

On wxHaskell, I try hard to ensure that everything works smoothly for Windows, Linux and Mac users because I want people to use the library. For my own purposes, I don’t need to care about Linux at all, and I use Mac only rarely. Many other library owners have the same attitude (e.g. the Gtk2HS team – and Gtk is one of the trickier libraries to get running on Windows, so it’s certainly possible).

In any case, I think that a large part of a better Windows story will be to have a standardized place where Cabal can look for libraries and headers, and use an external package manager like TakeoffGW to provide it.

At the very least, it would be helpful to have a ‘supported-platforms’ stanza in Cabal so that I could cabal list only those libraries which are supported on Windows, something like:

cabal list –supported-platforms=”msw”

Rather than discover that the library doesn’t work part way through compilation.

A handful of things could be helpful here:

1) The ability for the author to add comments to existing packages. This could be done by releasing with a new README, but something that’s more easily visible to Hackage would be good. The author can then add comments like “intended to be an alternative to …” and “deprecated in favor of …”.

2) Comments/feedback. Of course, this would have to be moderated. Perhaps a wiki organized around category and subcategory.

3) Auto-generated “connectedness” information. Hackage already shows dependencies, but inverting this and extending it would be useful:
Foo.Blah is used by 2: Bar.Door (4/18) Cow.Moo (1/3)
Notation here indicates that Bar.Door is used directly by 4 packages, and that the subgraph of Bar.Door contains 18 packages. This indicates that Bar.Door is pretty popular itself, so it’s use of Foo.Blah is a good recommendation. Conversely, Cow.Moo is only used by one other package, and the subgraph only contains 3 elements, so it’s a weaker recommendataion of Foo.Blah.