[darcs-users] enfranchising darcs?

[Don Stewart]

daveroundy:
> On Fri, Oct 17, 2008 at 12:24 PM, Don Stewart <dons at galois.com> wrote:
> > daveroundy:
> >> On Thu, Oct 16, 2008 at 2:25 PM, Jason Dagit <dagit at codersbase.com> wrote:
> >> > * Now it seems as though the plan is to throw autotools out the window on
> >> > all platforms and unconditionally.  Meaning that on POSIX platforms we are
> >> > changing something that isn't broken.
> >>
> >> No, the configure script *is* broken, it's just not as broken as cabal
> >> is.  It doesn't allow very good forward-compatibility, only
> >> backward-compatibility, meaning with every major release of ghc, darcs
> >> is broke, because the configure script needs to explicitly  mention
> >> every possible  package that might contain a module that  we use.
> >> Franchise fixes this bug.
> >
> > Could you summarise how cabal is broken?
> > Given that we build and distribute aroun 800 packages using Cabal now,
> > it's hard to imagine that it is horribly broken.
> 
> It requires that you know in advance the packages that are required to
> build a given project.
> 
> >> > has been under development for a few years and is now approaching a mature
> >> > status.  Cabal is tested, battle hardened, and all of hackage is built
> >> > regularly to ensure that it remains working as new features are added and
> >> > code is refactored.  Duncan is very responsive about bugs, there are summer
> >> > of code projects every summer for Cabal, it has a nice project website with
> >> > bugtracker and community, lots of documentation, tutorials around the net,
> >> > and otherwise seems very healthy and alive.  Recently Duncan gave a talk
> >> > about the future of Cabal[1] that sounds very promising.
> >>
> >> But as I've mentioned many times, cabal doesn't even attempt to
> >> replace autotools.  Given that I feel  (and windows-concerned users
> >> such as Zooko agree) that a configure that tests for the presence of
> >> libraries is importent, cabal is simply not an option.  Add  with that
> >> a complete lack of forward or backward compatibility, and you've got a
> >> tool that is really not a build system I would consider considering.
> >
> > Cabal implements extensive forward and backward compatibility support.
> > Somehow hackage keeps building, as new compilers appear, and new
> > libraries appear, and yet we don't need to update 800 .cabal files.
> >
> > Could you be more specific?
> 
> Cabal itself may be forward and backwards compatible, but applications
> that use it are not, they are quite tightly coupled to the version of
> cabal they were written for, and the versions of the compiler they
> were written for.  When a new ghc major release is put out, most cabal
> files need to be rewritten, and often in such a way that they won't
> work with older versions of cabal.

That's incorrect. For example, with the current GHC 6.10 relelase
candidate, currently 4% of packages break, mostly due to a changed
exception API in base (that is, the modules they depend on now have
different APIs). This issue also affects darcs.

So to say that 'most cabal files need to be written' is far, far from
accurate.  Perhaps you're exaggerating the downsides, while not
emphasising the upsides (namely, a cabalised package gets free
distribution and packaging, high visibility, easy install (cabal install
foo)).

> I define backwards compatibility as meaning that the build
> dependencies of darcs should not change with new releases of darcs,
> until we make an explicit decision to abandon a particular older
> configuration, and this choice should never be forced by the build
> system.  Cabal has historically explicitly violated this with every
> major ghc release since it has existed.  Perhaps you'll say that next
> time this won't happen? I prefer to look at past track record.

You mean, the build dependencies of darcs require updating, although
they will continue to change (e.g. darcs with ghc 6.10 now uses things
like QuickCheck 1.1, base-4, containers, perhaps syb).

Using module imports as the sole dependency tracking mechanism is good,
and intuitive, but how will you handle API changes within modules? A
versioning system, or simply picking the newest package that provides
that module?

> I define forwards compatibility as meaning that provided the darcs
> source code will compile with a future version of ghc, darcs will
> continue to compile without modification to the build system or source
> code.  Both the current autoconf system and the cabal system fail at
> forwards compatibility in the common case where modules move from one
> package to another or a package is renamed, since both of them rely on
> knowing in advance the possible package names corresponding to given
> modules.

That's true. You're expected to know what package the modules reside in.

I'd also worry about the investment though: cabal has taken 6 years to
write, and is comparable to darcs in size, but the result is a robust
package and distribution system used by 1000s of people. How much effort
can we hope to sync into franchise?

-- Don