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

[Gregory Crosswhite]

On 6/23/10 2:13 PM, Edward Kmett wrote:
> On Tue, Jun 22, 2010 at 4:54 PM, Gregory Crosswhite 
> <gcross at phys.washington.edu <mailto:gcross at phys.washington.edu>> wrote:
>
>     There is no reason that your program couldn't link to multiple
>     versions of the same package so that each library can access the
>     version that it needs.  In fact, GHC already does this, doesn't
>     it?  For example, I use a mixture of libraries in my programs that
>     link to QuickCheck 1 and QuickCheck 2, and this works just fine.
>
>
> This works fine as long as no detail of the embedded library leaks 
> into the public API. QuickCheck is typically the least painful library 
> to mix, since you don't typically use the quickcheck properties from 
> multiple quickcheck versions drawn from other packages at runtime.

Yes, but if details of the package you are using are "leaking" out into 
the interface then you will have the same kind of problems whenever that 
package conflicts with any other package, regardless of whether the 
conflict is with a package of the same name.  For example, for a while 
there was a conflict between mtl and transformers because they shared a 
package name, and the fact that the two packages had different names 
didn't make the problem any better.

>     The only problem I've had is with cabal, which when resolving
>     dependencies seems to only be able to pick out one version of a
>     package;  in some cases instead of running "cabal install A B"
>     where A and B depended on different versions of the same package
>     (QuickCheck) I had to instead separately run "cabal install A" and
>     "cabal install B".  This isn't a big deal, but I could imagine
>     cases where it could fail to automatically install a package
>     entirely due to conflicting version requirements.  This, however,
>     is not because there is an intrinsic problem with installing
>     multiple versions of a library, but simply because cabal sometimes
>     seems to get confused about what it needs to do.
>
>
> cabal is the only mechanism that the vast majority of Haskell-users 
> know how to use these days. Resolving diamond dependencies safely 
> relies on knowing tha tthe use of different libraries is entirely 
> internal to the library in question -- a detail that is not currently 
> exposed through the cabal file. You can use PackageImports to try and 
> hack around common package names at least in GHC, but it then further 
> confuses purpose and provenance.

But cabal can see with exactly which packages each of the dependencies 
requires, right?  So what is stopping it from just walking through the 
dependencies and constructing the dependency graph?  It should have all 
of the information it needs to do this.

To the extent that the full information that cabal needs exists and yet 
it is not capable of recognizing this, I would view this as a bug in 
cabal that we should fix, rather than deciding just to live with this 
bug and limiting ourselves to a subset of the package dependency 
functionality.

>     So in short, I see no problem with there being multiple versions
>     of a package floating around, and to the extent that an
>     implementation of something can't handle this it seems like this
>     is arguably a bug in that implementation rather than a bug in the
>     package system for allowing the possibility.
>
>
> There are multiple potential implementation semantics that can be 
> assigned to a diamond dependency. The types could be incompatible. 
> They could be compatible, and the most recent version should be used 
> by all (in case of minor API changes). They could be somewhere in between.

Yes, but again this will happen whenever you use two packages that 
conflict, regardless of whether they just happen to have the same name 
or not, as it did for a while with mtl and transformers.  Renaming fgl 
to newfgl won't actually make this situation any better.

> I suppose where we differ is in how big of a concern we view 'just 
> cabal having a problem with it' is. All I can say is that every time 
> there has been a major API change where half the community hasn't 
> moved, it has been a practical problem. It become yet another 
> implementation detail that every subsequent developer has needed to 
> consider, and providing support and instances for both is impractical.

My point isn't that it is not a big deal that cabal has a problem with 
it, it is that this is something that we should fix *in cabal* since 
there is nothing intrinsically intractable about it.  Furthermore, the 
kinds of problems that people encounter in such transitions won't be 
fixed merely by changing the name of the package since conflicts can 
still appear with the old package.

If we really are worried so much about these kinds of conflicts, then 
the real solution is to make sure that none of the modules exported by 
the new package share the same name as the modules in the old package.  
And if one is going to do that anyway, then from the perspective of 
resolving conflicts there isn't any additional benefit to also renaming 
the package.

Cheers,
Greg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100623/6afb7064/attachment.html