[Haskell-cafe] Rewriting a famous library and using the same name: pros and cons

[Ivan Lazar Miljenovic]

Edward Kmett <ekmett at gmail.com> writes:
>
> One much weaker consideration is that out of the 23+ direct dependencies on
> fgl, fully half of them don't bother to specify an upper bound on the fgl
> version and would break immediately. That said, those packages are out of
> compliance with package versioning policy. =)

I've contacted all the maintainers of those packages, and have received
replies from all but two maintainers promising to fix theirs (still
haven't heard from Aditya Mahajan for teams and John Morrice for
esotericbot).  Note that I'm just as guilty in this regard as I have
three packages that depend on fgl without upper bounds... >_>

I don't know how many of them have released fixed versions yet (I know I
haven't), but with the whole two versions of FGL needed thing: we're
going to work hard to help maintainers of packages that use FGL to
upgrade to the new version once we're satisfied with it and decide to
make the release official.  As such, we shouldn't have any problems of
packages depending transitively on two versions of FGL because most if
not all of them will get upgraded.

With FGL, we also have the situation where we have a "famous" library
that isn't actually used much:

* Out of those 23 direct dependencies on Hackage, 3 of them were by old
  versions of packages (i.e. they no longer use fgl); these are mpc, jhc
  and lhc.

* One is officially deprecated (scenegraph).

* 10 are pure libraries (note that some of these have no reverse
  dependencies, or if they do it's only by a few packages) (note that I
  included a package here if its executable seemed to only be for
  tests).

* 6 are executables only.

* 3 seem to be a library + an executable; only one of these has a
  reverse dependency and even then by one other package.

Out of the 25 indirect reverse dependencies:

* 20 (some of which are older versions only and thus not the latest) may
  transitively depend upon the old version of mps (either directly or
  via the hack library); because the dependencies on mps, etc. are
  open-ended for many of these it's difficult to tell if a new install
  will still transitively require fgl (as in to actually get it to
  work).

* 1 dependency on cabal-macosx

* 2 dependencies on lambdacube-engine (other lambdacube projects)

* 2 satchmo projects depending (transitively in one case) upon funsat.

As such, if we only consider transitive dependencies, then this issue of
one package using new and another old fgl is a non-issue as in all cases
as there's only a single point of contact with fgl.

>From what I can tell, fgl is more often used for internal projects
or executables rather than to create actual libraries.  So the whole
problem of worrying about multiple versions appears to be (no offense to
anyone) scare-mongering (or looking for possible problems due to bad
experiences with parsec, etc.).  With the 4 transitive dependencies on
fgl above, I'm not sure how many of them actually see any aspects of fgl
or if its all hidden inside the internal API of whatever package they
use.

Thus, once packages have proper reverse dependencies in their .cabal
files (as they should), then we should not really have a problem here if
a few packages don't upgrade at the same time or at all (except for
cases where a distribution only ships one version of each library and
wants to ship two different packages that depend upon different versions
of fgl).

Once again: we're going to do our very best to avoid the issues that
arose when parsec, QuickCheck, etc. had new major versions released and
packages transitively depended upon two different versions; however if
it does arise then it's going to be a very small localised problem.

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
IvanMiljenovic.wordpress.com