'temporary' package

[John Meacham]

On Sun, May 11, 2014 at 11:10 PM, Roman Cheplyaka <roma at ro-che.info> wrote:
> In this case I'm speaking as an open source library author, whose library
> depends on temporary.
>
> So no, cabal freeze can't help here.
>
> Roman

Have you considered autoconf? I know it is a painful syntax due to the
macro processing, but it is wicked powerful.

Rather than futz around with version numbers or having to magically
predict the future, I just have macros like
HC_CHECK_MODULE(Data.Foo,[baz::Int],[packagea,packageb,packagec]) and
it will check each package for the module with the id of the right
type and include the first it finds.

If a package maintainer changes behavior that in their mind wasn't
version breaking that affects me and decides not to bump a version
number it doesn't matter one bit, I just add a line in my conf file to
check for the bug and adapt. For more complicated things, I can check
things like whether instances are defined, size of types and whatnot,
all one liners. The best part is no need for version number archeology
or having to wait on anyone else or risk breaking someone else. Any
changes monotonically increase the portability without breaking it for
others.

If a package i need is "broken", and i want to release now, I just
include a patch to the third party package in my dist, autoconf checks
if it is needed and applies it before building the dependency, I have
the situation resolved in fifteen minutes rather than having to wait
on anyone blocking my release. and it is backwards and forwards
compatible, since it checks whether the patch is needed it won't apply
it to older versions and when the issue is fixed upstream then it is
just no longer applied.

I do have a longer term project dealing with autoconfs shortcomings in
a general way (mainly its sh/unix dependence and m4 quirkyness),
autoconf's pretty awful in some ways, but not nearly as bad as the
attempts to replace it.

   John

-- 
John Meacham - http://notanumber.net/