I think you're making this way harder than it really is.

What 99% of people need is that hackage packages builds with the latest haskell platform, and/or with bleeding edge ghc, and with the latest versions of its dependencies.

Thus for every dependency there is only one possible version - the latest one, and there are only a couple of compilers.

Having "special interest groups" for ghc 6.12 support and old versions of text is fine, but I think it is a pretty uninteresting problem to solve.

Likewise, supporting/fixing packages where the author for some reason *requires* use of a non-current version of some other package is also quite uninteresting (or at least outside the scope of my needs).   Such a package is basically just a relic.

Alexander

On 30 August 2012 22:26, Jay Sulzberger <jays@panix.com> wrote:


On Thu, 30 Aug 2012, Alexander Kjeldaas <alexander.kjeldaas@gmail.com> wrote:

This is very unfortunate, but this is crucially a tooling issue.  I am
going to wave my hands, but..

Ignore the mapreduce in the following video, but look at the use of clang
to do automatic refactoring of C++.  This is *incredibly* powerful in
dealing with updates to APIs.

http://www.llvm.org/devmtg/2011-11/videos/Carruth_ClangMapReduce-desktop.mp4

But without all that fancy tech, *just* having all of Hackage source code
in one repository and using perl/regexps, fixing these types of issues is
O(1) instead of O(n).

All of the issues you mention seems to be fixable by a few lines of perl
*if we had the repository*.

Better to do this with sexps.

ad repositories: Part of the general problem of managing a
repository is close to the problem of inferring a good type for
(the value of) an expression.  The style of constraints is
similar.  Now the design problem is:

1. Arrange a general system for the specification of the
   constraints.

2. Design a systematic way of giving both advice and direct
   commands to the system.  This subsystem would be used to set
   up the default policy.

3. Choose a constraint solver.

Maybe worth looking at:

  http://en.wikipedia.org/wiki/Nix_package_manager
  [page was last modified on 17 July 2012 at 20:20]

oo--JS.



[a few hours later]

Actually, I went and downloaded all of hackage, put it into a git
repository and fixed these issues:

Fix catch
perl -ni -e 'print unless /import Prelude hiding \(catch\)/' $(git grep
'import Prelude hiding (catch)')

Fix CInt constructors (lots of other stuff from Foreign.C.Types not fixed
though)
perl -p -i -e 's/^import Foreign.C.Types(.*)CInt([^(])/import
Foreign.C.Types${1}CInt(..)${1}/g' $(git grep -l '^import.*CInt')

Fix bytestring versioning
perl -p -i -e 's/bytestring( +)>=([0-9. &]+)<([
]*)0.10/bytestring$1>=$2<${3}0.11/g' $(git grep 'bytestring.*< *0\.')

Patch to hackage:
http://ge.tt/6Cb5ErM/v/0

I understand that this doesn't help anyone, but if there was a way fix,
upload, and get *consensus* on a few regexps like this, then doing API
changes wouldn't be such a headache.

Alexander

On 30 August 2012 07:26, Bryan O'Sullivan <bos@serpentine.com> wrote:

Since the release of the GHC 7.6 RC, I've been going through my packages
and fixing up build problems so that people who upgrade to 7.6 will have a
smooth ride.

Sad to say, my experience of 7.6 is that it has felt like a particularly
rough release for backwards incompatibility. I wanted to quantify the pain,
so I did some research, and here's what I found.

I maintain 25 open source Haskell packages. Of these, the majority have
needed updates due to the GHC 7.6 release:

   - base16-bytestring
   - blaze-textual
   - bloomfilter
   - configurator
   - criterion
   - double-conversion
   - filemanip
   - HDBC-mysql
   - mwc-random
   - pcap
   - pool
   - riak-haskell-client
   - snappy
   - text
   - text-format
   - text-icu


That's 16 out of 25 packages I've had to update. I've also either reported
bugs on, or had to fix, several other people's packages along the way
(maybe four?). So let's say I've run into problems with 20 out of the
combined 29 packages of mine and my upstreams.

The reasons for these problems fall into three bins:

   - Prelude no longer exports catch, so a lot of "import Prelude hiding
   (catch)" had to change.
   - The FFI now requires constructors to be visible, so "CInt" has to be
   imported as "CInt(..)".
   - bytestring finally got bumped to 0.10, so many upper bounds had to
   be relaxed (*cf* my suggestion that the upper-bounds-by-default policy

   is destructive).

It has been a lot of work to test 29 packages, and then modify, rebuild,
and release 20 of them. It has consumed most of my limited free time for
almost two weeks. Worse, this has felt like make-work, of no practical
benefit to anyone beyond scrambling to restore the status quo ante.

If over half of my packages needed fixing, I'm alarmed at the thought of
the effects on the rest of Hackage.

I'm torn over this. I understand and agree with the impetus to improve the
platform by tidying things up, and yet just two seemingly innocuous changes
(catch and FFI) have forced me to do a bunch of running to stand still.

I don't have any suggestions about what to do; I know that it's hard to
estimate the downstream effects of what look like small changes. And so I'm
not exactly complaining. Call this an unhappy data point.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe




_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe