Replying somewhere random in the thread.
Linux distributions have to solve this same problem. We first need to
decide what Hackage's function is supposed to be:
(1) A dumb repository to host Haskell code
(2) A collection of Haskell packages that work together
In reality it's (1), but the ex
On 09/11/2012 18:35, Clark Gaebel wrote:
> I think we just use dependencies different things. This is a problem
> inherent in cabal.
>
> When I (and others) specify a dependency, I'm saying "My package will
> work with these packages. I promise."
> When you (and others) specify a dependency, you'r
Hi Tobias,
>> When such a situation has arisen in the past, it's my experience
>> that the author of B typically releases an update to fix the issue
>> with the latest version of C:
>>
>> B 2.5.4.0 build-depends: C >= 3.8
>>
>> So that particular conflict does hardly ever occur in practic
Ketil Malde wrote:
> Aleksey Khudyakov writes:
>
>>> Adding more restrictive constraints does not work, the broken package will
>>> be on hackage forever, while adding a new version with relaxed constraints
>>> works well.
>
>> That illustrate real problem It's not possible to specify correct
>
Peter Simons wrote:
> Hi Tobias,
>
> > A 1.1.4.0 build-depends: B ==2.5.* C ==3.7.* (overspecified)
> > B 2.5.3.0 build-depends: C ==3.* (underspecified)
> > C 3.7.1.0
> >
> > Everything works nice until C-3.8.0.0 appears with incompatible changes
> > that break B, but not A.
> >
> > Now
Hi Tobias,
> A 1.1.4.0 build-depends: B ==2.5.* C ==3.7.* (overspecified)
> B 2.5.3.0 build-depends: C ==3.* (underspecified)
> C 3.7.1.0
>
> Everything works nice until C-3.8.0.0 appears with incompatible changes
> that break B, but not A.
>
> Now both A and B have to update their depende
Aleksey Khudyakov writes:
>> Adding more restrictive constraints does not work, the broken package will
>> be on hackage forever, while adding a new version with relaxed constraints
>> works well.
> That illustrate real problem It's not possible to specify correct
> version constraints when pack
> The blacklisting approach has one major disadvantage that noone has
> mentioned yet:
> Adding more restrictive constraints does not work, the broken package will
> be on hackage forever, while adding a new version with relaxed constraints
> works well.
>
That illustrate real problem It's not poss
On 11/14/2012 09:53 AM, Ivan Lazar Miljenovic wrote:
% cabal install virthualenv
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: virthualenv-0.2.1
rejecting: base-3.0.3.2, 3.0.3.1 (global constraint requires installed
instance)
rejecting: base-4.6.0.0
Johan Tibell wrote:
> On Wed, Nov 14, 2012 at 1:01 PM, Tobias Müller wrote:
>
> Clark Gaebel wrote:
> To prevent this, I think the PVP should specify that if dependencies get
> a major version bump, the package itself should bump its major version
> (preferably the B field).
>
> No, it has not
On Wed, Nov 14, 2012 at 1:01 PM, Tobias Müller wrote:
> Clark Gaebel wrote:
> > To prevent this, I think the PVP should specify that if dependencies get
> > a major version bump, the package itself should bump its major version
> > (preferably the B field).
>
> No, it has nothing to do with majo
Clark Gaebel wrote:
> To prevent this, I think the PVP should specify that if dependencies get
> a major version bump, the package itself should bump its major version
> (preferably the B field).
No, it has nothing to do with major/minor version bumps. It's just that if
you underspecify your depe
To prevent this, I think the PVP should specify that if dependencies get a
major version bump, the package itself should bump its major version
(preferably the B field).
Hopefully, in the future, cabal would make a distinction between packages *
used* within another package (such as a hashmap excl
Peter Simons wrote:
> Hi Clark.
>
> > I think we just use dependencies [to specify] different things.
>
> If dependency version constraints are specified as a white-list --
> i.e. we include only those few versions that have been actually
> verified and exclude everything else --, then we take
On Wed, Nov 14, 2012 at 10:57 AM, Roman Cheplyaka wrote:
> * Ivan Lazar Miljenovic [2012-11-14
> 20:53:23+1100]
> > Doesn't this prevent the error of "this package won't build" (even if
> > the error message doesn't precisely say that)?
>
> Yeah, it replaces one error with another. How is it sup
* Ivan Lazar Miljenovic [2012-11-14 20:53:23+1100]
> Doesn't this prevent the error of "this package won't build" (even if
> the error message doesn't precisely say that)?
Yeah, it replaces one error with another. How is it supposed to help me
if I really want to build this package? Instead of fi
On 14 November 2012 20:35, Roman Cheplyaka wrote:
> * Erik Hesselink [2012-11-12 20:58:17+0100]
>> And I believe the last base changes included a change to 'catch' which
>> would have broken a lot of packages. The Num changes also caused a lot of
>> code changes, and there were probably more I do
* Erik Hesselink [2012-11-12 20:58:17+0100]
> And I believe the last base changes included a change to 'catch' which
> would have broken a lot of packages. The Num changes also caused a lot of
> code changes, and there were probably more I don't remember.
Even if so, upper bounds don't prevent th
Especially in the case of base, not sure how upper bounds help at all:
If incompatible, you break with or without upper bounds. Actually getting
errors related to Num instances is more informative IMO.
If compatible, you just get false negatives and errors.
In either case cabal can't install an
On Mon, Nov 12, 2012 at 5:13 PM, Johan Tibell wrote:
> On Mon, Nov 12, 2012 at 1:06 AM, Erik Hesselink wrote:
>
>> tl;dr: Breakages without upper bounds are annoying and hard to solve for
>> package consumers. With upper bounds, and especially with sandboxes,
>> breakage is almost non-existent.
>>
On Mon, Nov 12, 2012 at 1:06 AM, Erik Hesselink wrote:
> tl;dr: Breakages without upper bounds are annoying and hard to solve for
> package consumers. With upper bounds, and especially with sandboxes,
> breakage is almost non-existent.
>
> I don't see how things break with upper bounds, at least
tl;dr: Breakages without upper bounds are annoying and hard to solve for
package consumers. With upper bounds, and especially with sandboxes,
breakage is almost non-existent.
I don't see how things break with upper bounds, at least in the presence of
sandboxes. If all packages involved follow the
Peter Simons writes:
[...]
> Now, the black-list approach has a significant advantage. In current
> versions of "cabal-install", it is possible for users to extend an
> incomplete black-list by adding appropriate "--constraint" flags on
> the command-line of the build. It is impossible, however,
Hi Clark.
> I think we just use dependencies [to specify] different things.
If dependency version constraints are specified as a white-list --
i.e. we include only those few versions that have been actually
verified and exclude everything else --, then we take the risk of
excluding *too much*. T
* Erik Hesselink [2012-11-10 16:40:30+0100]
> On Fri, Nov 9, 2012 at 5:52 PM, Roman Cheplyaka wrote:
>
> > * Janek S. [2012-11-09 17:15:26+0100]
> > > but I am aware that if the library were to be released on Hackage I
> > > would have to supply version numbers in the dependencies. The question
On Fri, Nov 9, 2012 at 5:52 PM, Roman Cheplyaka wrote:
> * Janek S. [2012-11-09 17:15:26+0100]
> > but I am aware that if the library were to be released on Hackage I
> > would have to supply version numbers in the dependencies. The question
> > is how to determine proper version numbers?
>
> Wi
I think we just use dependencies different things. This is a problem
inherent in cabal.
When I (and others) specify a dependency, I'm saying "My package will work
with these packages. I promise."
When you (and others) specify a dependency, you're saying "If you use a
version outside of these bound
Hi Clark,
> It's not restrictive.
how can you say that by adding a version restriction you don't restrict
anything?
> I just don't like to claim that my package works with major versions
> of packages that I haven't tested.
Why does it not bother you to claim that your package can *not* be
It's not restrictive. Anything that I put on Hackage is open source. If
someone finds that it works fine on a previous (or later) version, I accept
their patch with a constraint change, and re-release immediately. I just
don't like to claim that my package works with major versions of packages
that
> I usually just take the easy way out and switch to ==0.7.
I see. I guess I don't yet have enough experience in Haskell to anticipate how
restrictive is such
a choice.
Janek
>
> On Fri, Nov 9, 2012 at 11:31 AM, Janek S. wrote:
> > Thanks Clark! You're method seems good at first but I think I
Hi Janek,
> How to determine proper version numbers?
if you know for a fact that your package works only with specific
versions of its dependencies, then constrain the build to exactly those
versions that you know to work.
If *don't* know of any such limitations, then *don't* specify any
constr
Just like if your C application depends on either SQLite 2 or SQLite 3,
you're going to need to test it with both before a release.
Hoping that your library works against a previous major revision is just
asking for trouble!
I usually just take the easy way out and switch to ==0.7.
On Fri, Nov
* Janek S. [2012-11-09 17:15:26+0100]
> but I am aware that if the library were to be released on Hackage I
> would have to supply version numbers in the dependencies. The question
> is how to determine proper version numbers?
With the current state of affairs, your best bet is not to specify any
Thanks Clark! You're method seems good at first but I think I see a problem. So
let's say you
started with aeson 0.6. As new versions of aeson are released you introduce
version ranges, but
do you really have a method to determine that your package does indeed work
with earlier
versions? If y
What I usually do is start out with dependencies listed like:
aeson ==0.6.*
and then, as your dependencies evolve, you either bump the version number:
aeson ==0.7.*
or, if you're willing to support multiple version, switch to a range:
aeson >=0.6 && <= 0.7
If someone uses a previous version o
Recently I started developing a Haskell library and I have a question about
package dependencies.
Right now when I need my project to depend on some other package I only specify
the package name
in cabal file and don't bother with providing the package version. This works
because I am the
onl
36 matches
Mail list logo
