On 6/23/10 10:06 PM, Duncan Coutts wrote:
Suppose both the zlib and tar packages specify build-depends:
bytestring-0.9.*. It's entirely possible for me to install zlib, then
upgrade to a new bugfix release of bytestring, install tar (using the
new bytestring) and then build htar depending on
On Tue, Jun 22, 2010 at 4:54 PM, Gregory Crosswhite
gcr...@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
On 6/23/10 2:13 PM, Edward Kmett wrote:
On Tue, Jun 22, 2010 at 4:54 PM, Gregory Crosswhite
gcr...@phys.washington.edu mailto:gcr...@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
On Wed, Jun 23, 2010 at 2:57 PM, Gregory Crosswhite
gcr...@phys.washington.edu wrote:
On 6/23/10 2:13 PM, Edward Kmett wrote:
On Tue, Jun 22, 2010 at 4:54 PM, Gregory Crosswhite
gcr...@phys.washington.edu wrote:
There is no reason that your program couldn't link to multiple versions of
On 6/23/10 3:29 PM, Edward Kmett wrote:
Yes, and that problem still isn't resolved in another since, since
they share the same module names, but as of yet, still provide an
incompatible API. I can't (yet) provide 'RightSemiNearRing' instances
that work with both the monad transformers from
Edward Kmett ekm...@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
On 23 June 2010 19:57, Gregory Crosswhite gcr...@phys.washington.edu wrote:
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
On 6/23/10 8:06 PM, Duncan Coutts wrote:
Consider an example where we want to avoid using two versions of a dependency:
The htar program depends on the tar and zlib packages. The tar and
zlib packages depend on bytestring. Both tar and zlib export functions
that use the type ByteString. The
On Wed, 2010-06-23 at 21:05 -0400, Gregory Crosswhite wrote:
On 6/23/10 8:06 PM, Duncan Coutts wrote:
Consider an example where we want to avoid using two versions of a
dependency:
The htar program depends on the tar and zlib packages. The tar and
zlib packages depend on bytestring.
On Tue, Jun 08, 2010 at 11:21:54AM -0700, Gregory Crosswhite wrote:
Or you just put an upper bound on the versions of the fgl library that
your program will build against, as you should be doing anyway, and
then nothing breaks.
Until some package you rely on decides to upgrade and start using
The problem is that nothing breaks immediately.
Then someone else comes along and transitively depends on your package and
on another package, which depends on the newer version.
Your users wind up with strange conflicts like that if they are using Parsec
3 they can't use HTTP.
Or if they use
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
There have been a few cases of major API / rewrites to famous old
packages causing problems, including:
* QuickCheck 1 vs 2
* parsec 2 vs 3
* OpenGL
a similar opportunity is present with 'fgl', where the new maintainers
are seeking to improve the code.
Below I try to summarise
On Tue, Jun 8, 2010 at 8:08 AM, Don Stewart d...@galois.com wrote:
(... There have been a few cases of major API / rewrites to famous old
packages causing problems, including:
* QuickCheck 1 vs 2
* parsec 2 vs 3
* OpenGL
...)
(... * No additional breakages are introduced.
Or you just put an upper bound on the versions of the fgl library that your
program will build against, as you should be doing anyway, and then nothing
breaks.
Cheers,
Greg
On Jun 8, 2010, at 11:08 AM, Gene A wrote:
On Tue, Jun 8, 2010 at 8:08 AM, Don Stewart d...@galois.com wrote:
On Tuesday 08 June 2010 20:21:54, Gregory Crosswhite wrote:
Or you just put an upper bound on the versions of the fgl library that
your program will build against, as you should be doing anyway, and then
nothing breaks.
Cheers,
Greg
Right. At least, nothing breaks until the next compiler
Gene A yumag...@gmail.com writes:
Oh lord yes... just call it fgl3 and leave the fgl package alone.
This is a source based community here... so you take a package that
has a dependency on another library and you go out and get that to
cover the dependency and the API is not the same!!! AND
Sorry, I hit Reply instead of Reply To All.
-- Forwarded message --
From: Jake McArthur jake.mcart...@gmail.com
Date: Tue, Jun 8, 2010 at 6:16 PM
Subject: Re: [Haskell-cafe] Rewriting a famous library and using the
same name: pros and cons
To: Don Stewart d...@galois.com
Making
18 matches
Mail list logo
