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 ta
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 byte
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 htar
On 23 June 2010 19:57, Gregory Crosswhite 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 library in
> question -- a
Edward Kmett 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.
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 tran
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 ver
On 6/23/10 2:13 PM, Edward Kmett wrote:
On Tue, Jun 22, 2010 at 4:54 PM, Gregory Crosswhite
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 the
version that it need
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 ex
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
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 fc
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 usin
Sorry, I hit Reply instead of Reply To All.
-- Forwarded message --
From: Jake McArthur
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
Making a new name for an existing package
Gene A 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 especially if
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 compil
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 wrote:
>
> (... There ha
On Tue, Jun 8, 2010 at 8:08 AM, Don Stewart 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. ...)
>
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 the
18 matches
Mail list logo
