[Haskell-cafe] The instability of Haskell libraries

[Thomas Hartman]

1) Folks, what exactly is the situation with buildbots?
2) Easily available images for installing virtualized environments
could also ameliorate the pain, no?

wrt 1) It seems to me that in an ideal world you could have a
candidate for uploading to hackage, but before uploading you could
push a magic button and get a message within one hour stating whether
this broke any packages on hackage.

I start thinking about a (cloneable) community ec2 or slicehost server
for buildbot -- 72 bucks a month should be doable for a community in
the thousands.

Does this make sense? Is it within the realm of possibility? What
would it take to make it happen?

I made a baby step in the direction of 2) with

http://blog.patch-tag.com/2010/02/12/ec2-amis-for-gitit-happstack/

At the very least, what this means for me personally is that I (or
anybody) can spin up a working box with gitit installed on it, for
some past incarnation of gitit/happstack/haskell platform.

Now, what happens when you attempt to cabal update && cabal reinstall
gitit -- I dunno. Very possibly breakage.

But at least you get a working place to start from.

I can see how this might apply to other pain points that I have less
personal knowledge of, like glut (?) & many others.

thomas.

2010/4/23 Jason Dagit <dagit at codersbase.com>:
>
>
> On Fri, Apr 23, 2010 at 11:34 AM, John Goerzen <jgoerzen at complete.org>
> wrote:
>>
>> A one-character change.  Harmless?  No.  It entirely changes what the
>> function does.  Virtually any existing user of that function will be
>> entirely broken.  Of particular note, it caused significant breakage in the
>> date/time handling functions in HDBC.
>>
>> Now, one might argue that the function was incorrectly specified to begin
>> with.  But a change like this demands a new function; the original one ought
>> to be commented with the situation.
>>
>> My second example was the addition of instances to time.  This broke code
>> where the omitted instances were defined locally.  Worse, the version number
>> was not bumped in a significant way to permit testing for the condition, and
>> thus conditional compilation, via cabal.  See http://bit.ly/cBDj3Q for more
>> on that one.
>
> This is of course in part due to a strength of cabal (remember that
> strengths and weaknesses tend to come together).  Cabal discourages testing
> libraries/apis at configure time.  The result is that version numbers need
> to encode this information.  We don't (yet), have a tool to help detect when
> a change in version number is needed or what the next version should be.  We
> leave this up to humans and it turns out, humans make mistakes :)
>
> Even once we have an automatic tool to enforce/check the package version
> policy, mistakes may still sneak in.  I would expect the 'T' in the time
> format to be in this same category.  More about that below.
>
>>
>> I don't have a magic bullet to suggest here.  But I would first say that
>> this is a plea for people that commit to core libraries to please bear in
>> mind the implications of what you're doing.  If you change a time format
>> string, you're going to break code.  If you introduce new instances, you're
>> going to break code.  These are not changes that should be made lightly, and
>> if they must be made (I'd say there's a stronger case for the time instances
>> than the s/ /T/ change), then the version number must be bumped
>> significantly enough to be Cabal-testable.
>
> While I haven't participated in the library proposal process myself, I was
> under the impression that Haskell has a fairly rigorous process in place for
> modifying the core libraries.  Is the above change too small to for that
> process?  Did that process simply fail here?
>
> Jason
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>