Just thinking aloud:
What if we add -current ?
pacage -current
Would select the versions of the package that were current art the time the
cabal file was uploaded and sucessfully compiled in hackage, if the packae
is installed from hackage
If the cabal file is local then current == any.
On 8/22/12 9:18 AM, Leon Smith wrote:
I think we actually agree more than we disagree; I do think distinguishing
hard and soft upper bounds (no matter what they are called) would help,
and I'm just trying to justify them to some of the more dismissive
attitudes towards the idea
Hopefully.
On 8/22/12 12:35 PM, David Menendez wrote:
As I see it, there are four possibilities for a given version of dependency:
1. The version DOES work. The author (or some delegate) has compiled
the package against this version and the resulting code is considered
good.
2. The version SHOULD work. No
I think we actually agree more than we disagree; I do think distinguishing
hard and soft upper bounds (no matter what they are called) would help,
and I'm just trying to justify them to some of the more dismissive
attitudes towards the idea
The only thing I think we (might) disagree on is the
As I see it, there are four possibilities for a given version of dependency:
1. The version DOES work. The author (or some delegate) has compiled
the package against this version and the resulting code is considered
good.
2. The version SHOULD work. No one has tested against this version,
but the
I am strongly against this, especially for packages in the platform.
If you fail to specify an upper bound, and I depend on your package,
your dependencies can break my package! For example, say I develop
executable A and I depend on library B == 1.0. Library B depends on
library C = 0.5 (no
Sent: 20 August 2012 08:33
To: Bryan O'Sullivan
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not
our friends
I am strongly against this, especially for packages in the platform.
If you fail to specify an upper bound, and I depend on your
On 15/08/2012 21:44, Johan Tibell wrote:
On Wed, Aug 15, 2012 at 1:02 PM, Brandon Allbery allber...@gmail.com wrote:
So we are certain that the rounds of failures that led to their being
*added* will never happen again?
It would be useful to have some examples of these. I'm not sure we had
O'Sullivan
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not
our friends
I am strongly against this, especially for packages in the platform.
If you fail to specify an upper bound, and I depend on your package, your
dependencies can
My two (or three) cents:
- Given a choice between a world where there is tedious work for package
maintainers vs. a world where packages randomly break for end users (giving
them a bad impression of the entire Haskell ecosystem), I choose the former.
- More automation can ease the
-Original Message-
From: Erik Hesselink [mailto:hessel...@gmail.com]
Sent: 20 August 2012 14:35
To: Chris Dornan
Cc: Bryan O'Sullivan; haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not
our friends
Hub looks interesting, I'll have to try
On Thu, Aug 16, 2012 at 06:07:06PM -0400, Joey Adams wrote:
On Wed, Aug 15, 2012 at 3:38 PM, Bryan O'Sullivan b...@serpentine.com wrote:
I propose that the sense of the recommendation around upper bounds in the
PVP be reversed: upper bounds should be specified only when there is a known
Hello,
I also completely agree with Bryan's point which is why I usually don't add
upper bounds on the dependencies of the packages that I maintain---I find
that the large majority of updates to libraries tend to be backward
compatible, so being optimistic seems like a good idea.
By the way,
On Sat, Aug 18, 2012 at 3:57 AM, David Feuer david.fe...@gmail.com wrote:
If the language is changed (without possibility of breakage, I
believe) so that names declared in a module shadow imported names,
incompatibility can only arise if two different imports offer the same
name, and it is
Message-
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of MightyByte
Sent: 16 August 2012 04:02
To: Ivan Lazar Miljenovic
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not
our friends
On Wed, Aug 15, 2012 at 9
On Thu, Aug 16, 2012 at 9:53 AM, Felipe Almeida Lessa
felipe.le...@gmail.com wrote:
If you import qualified then adding functions will never break anything.
If the language is changed (without possibility of breakage, I
believe) so that names declared in a module shadow imported names,
On 8/17/12 11:28 AM, Leon Smith wrote:
And the
difference between reactionary and proactive approaches I think is a
potential justification for the hard and soft upper bounds; perhaps we
should instead call them reactionary and proactive upper bounds instead.
I disagree. A hard constraint
On Thu, Aug 16, 2012 at 11:33:17PM -0400, wren ng thornton wrote:
However, there are certainly cases where we have hard upper
bounds[1][2][3], and ignoring those is not fine. Circumventing hard
upper bounds should require altering the .cabal file, given as
getting things to compile will
Brent Yorgey wrote:
Yitzchak Gale wrote:
For actively maintained packages, I think the
problem is that package maintainers don't find
out promptly that an upper bound needs to be
bumped. One way to solve that would be a
simple bot that notifies the package maintainer
as soon as an upper bound
My thoughts on the matter got a little long, so I posted them here:
http://nominolo.blogspot.co.uk/2012/08/beyond-package-version-policies.html
On 17 August 2012 12:48, Heinrich Apfelmus apfel...@quantentunnel.dewrote:
Brent Yorgey wrote:
Yitzchak Gale wrote:
For actively maintained
I see good arguments on both sides of the upper bounds debate, though at
the current time I think the best solution is to omit upper bounds (and I
have done so for most/all of my packages on hackage).But I cannot agree
with this enough:
On Thu, Aug 16, 2012 at 4:45 AM, Joachim Breitner
What if instead of upper (and lower) bounds we just specify our interface
requirements? Like package bull-shit should provide value Foo.Bar.baz ::
forall a. [a] - [a] - [a] or more general. Sure, it won't help dealing with
strictness/lazyness, but it would capture most interface differences.
On Fri, Aug 17, 2012 at 12:34 PM, MigMit miguelim...@yandex.ru wrote:
What if instead of upper (and lower) bounds we just specify our interface
requirements?
We already have a simple versioning scheme for which, despite it being easy
to grasp, we have amply demonstrated that we cannot make it
On Aug 18, 2012, at 12:35 AM, Bryan O'Sullivan b...@serpentine.com wrote:
We already have a simple versioning scheme for which, despite it being easy
to grasp, we have amply demonstrated that we cannot make it work well,
because it has emergent properties that cause it to not scale well
On Fri, Aug 17, 2012 at 4:35 PM, Bryan O'Sullivan b...@serpentine.comwrote:
Any vastly more complicated and detailed versioning scheme has a huge
burden to prove that it won't collapse dramatically more quickly. (Frankly,
I think that anything involving specify every detail of your known
I agree that Haskell's design gives us a good leg up on the problem of
acquiring and comparing APIs. However, I don't think that this
manifest solution really buys us enough to justify the complexity.
There're also some specific, perhaps resolvable, but unsightly problems, which
I outline here:
On 8/16/12 11:33 PM, wren ng thornton wrote:
[1] Parsec 2 vs 3, for a very long time
[2] mtl 1 vs 2, for a brief interim
[3] John Lato's iteratee =0.3 vs =0.4, for legacy code
...
I think this is a great point! As others have said, maintainers
typically, but not always, know when their code
On Wed, Aug 15, 2012 at 03:54:04PM -0700, Michael Sloan wrote:
Upper bounds are a bit of a catch-22 when it comes to library authors evolving
their APIs:
1) If library clients aren't encouraged to specify which version of the
exported API they target, then changing APIs can lead to
Bryan O'Sullivan b...@serpentine.com writes:
I propose that the sense of the recommendation around upper bounds in the
PVP be reversed: upper bounds should be specified *only when there is a
known problem with a new version* of a depended-upon package.
Another advantage to this is that it's
I am tentatively in agreement that upper bounds are causing more
problems than they are solving. However, I want to suggest that
perhaps the more fundamental issue is that Cabal asks the wrong person
to answer questions about API stability. As a package author, when I
release a new version, I
On 16/08/12 14:07, Chris Smith wrote:
As a package author, when I
release a new version, I know perfectly well what incompatible changes
I have made to it... and those might include, for example:
1. New modules, exports or instances... low risk
2. Changes to less frequently used, advanced, or
Twan van Laarhoven twa...@gmail.com wrote:
Would adding a single convenience function be low or high risk? You say it
is low risk, but it still risks breaking a build if a user has defined a
function with the same name.
Yes, it's generally low-risk, but there is *some* risk. Of course, it
On 16 August 2012 20:50, Ketil Malde ke...@malde.org wrote:
Bryan O'Sullivan b...@serpentine.com writes:
I propose that the sense of the recommendation around upper bounds in the
PVP be reversed: upper bounds should be specified *only when there is a
known problem with a new version* of a
to write software, if
you spend all of your time waiting for someone else to update their
libraries.
Timothy
-- Původní zpráva --
Od: Ivan Lazar Miljenovic ivan.miljeno...@gmail.com
Datum: 16. 8. 2012
Předmět: Re: [Haskell-cafe] Platform Versioning Policy: upper bounds
On Thu, Aug 16, 2012 at 10:01 AM, Chris Smith cdsm...@gmail.com wrote:
Twan van Laarhoven twa...@gmail.com wrote:
Would adding a single convenience function be low or high risk? You say it
is low risk, but it still risks breaking a build if a user has defined a
function with the same name.
Bryan O'Sullivan wrote:
A substantial number of the difficulties I am encountering are related to
packages specifying upper bounds on their dependencies. This is a recurrent
problem, and its source lies in the recommendations of the PVP itself
I think the PVP recommendation is good, though
On Wed, Aug 15, 2012 at 9:38 PM, Bryan O'Sullivan b...@serpentine.comwrote:
A benign change will obviously have no visible effect, while a compilation
failure is actually *better* than a depsolver failure, because it's more
informative.
But with upper bounds you give Cabal a chance to try
On Thu, Aug 16, 2012 at 05:30:07PM +0300, Yitzchak Gale wrote:
For actively maintained packages, I think the
problem is that package maintainers don't find
out promptly that an upper bound needs to be
bumped. One way to solve that would be a
simple bot that notifies the package maintainer
On Wed, Aug 15, 2012 at 3:38 PM, Bryan O'Sullivan b...@serpentine.com wrote:
I propose that the sense of the recommendation around upper bounds in the
PVP be reversed: upper bounds should be specified only when there is a known
problem with a new version of a depended-upon package.
I, too,
On 8/15/12 11:02 PM, MightyByte wrote:
One tool-based way to help with this problem would
be to add a flag to Cabal/cabal-install that would cause it to ignore
upper bounds.
I'd much rather have a distinction between hard upper bounds (known to
fail with) vs soft upper bounds (tested with).
On Wed, Aug 15, 2012 at 12:38 PM, Bryan O'Sullivan b...@serpentine.com wrote:
I propose that the sense of the recommendation around upper bounds in the
PVP be reversed: upper bounds should be specified only when there is a known
problem with a new version of a depended-upon package.
This
On Wed, Aug 15, 2012 at 3:57 PM, Johan Tibell johan.tib...@gmail.comwrote:
On Wed, Aug 15, 2012 at 12:38 PM, Bryan O'Sullivan b...@serpentine.com
wrote:
I propose that the sense of the recommendation around upper bounds in the
PVP be reversed: upper bounds should be specified only when
On Wed, Aug 15, 2012 at 1:02 PM, Brandon Allbery allber...@gmail.comwrote:
So we are certain that the rounds of failures that led to their being
*added* will never happen again?
Of course I am sure that problems will arise as a result of recommending
that upper bounds be added reactively;
On Wed, Aug 15, 2012 at 1:02 PM, Brandon Allbery allber...@gmail.com wrote:
So we are certain that the rounds of failures that led to their being
*added* will never happen again?
It would be useful to have some examples of these. I'm not sure we had
any when we wrote the policy (but Duncan
Would it make sense to have a known-to-be-stable-though soft upper bound
added proactively, and a known-to-break-above hard bound added reactively,
so people can loosen gracefully as appropriate?
On Aug 15, 2012 1:45 PM, Johan Tibell johan.tib...@gmail.com wrote:
On Wed, Aug 15, 2012 at 1:02 PM,
On Wed, Aug 15, 2012 at 1:50 PM, David Thomas davidleotho...@gmail.comwrote:
Would it make sense to have a known-to-be-stable-though soft upper bound
added proactively, and a known-to-break-above hard bound added reactively,
so people can loosen gracefully as appropriate?
I don't think so. It
it's usual for the existing upper bounds to refer to versions that don't
exist at the time of writing (and hence can't be known to be stable).
Well, known to be stable given semantic versioning, then.
http://semver.org/
On Wed, Aug 15, 2012 at 1:55 PM, Bryan O'Sullivan b...@serpentine.com
As someone who recurrently is nudging a large number of maintainers every
major ghc release to bump their bounds, I favor the no upper bounds
approach! :)
plus the whole improving ecosystem of build bot tools which play nice with
cabal et al that are cropping up mean that in principal we could
I definitely agree!
http://www.reddit.com/r/haskell/comments/x4knd/what_is_the_reason_for_haskells_cabal_package/
L.
On Wed, Aug 15, 2012 at 12:38:33PM -0700, Bryan O'Sullivan wrote:
Hi, folks -
I'm sure we are all familiar with the phrase cabal dependency hell at this
point, as the number
On Wed, Aug 15, 2012 at 4:44 PM, Johan Tibell johan.tib...@gmail.comwrote:
On Wed, Aug 15, 2012 at 1:02 PM, Brandon Allbery allber...@gmail.com
wrote:
So we are certain that the rounds of failures that led to their being
*added* will never happen again?
It would be useful to have some
no one is disputing that there are conditional changes in dependencies
depending on library versions.
an interesting intermediate point would be have a notion of testing with
constraints in cabal and engineering cabal to support a
--withTestedConstraints to have a simple composable way of
Upper bounds are a bit of a catch-22 when it comes to library authors evolving
their APIs:
1) If library clients aren't encouraged to specify which version of the
exported API they target, then changing APIs can lead to opaque compile
errors (without any information about which API is
On Wed, Aug 15, 2012 at 6:46 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
no one is disputing that there are conditional changes in dependencies
depending on library versions.
Indeed. But the ghc release that split up base broke cabalised packages
with no warning to users until
On 16 August 2012 08:55, Brandon Allbery allber...@gmail.com wrote:
On Wed, Aug 15, 2012 at 6:46 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
no one is disputing that there are conditional changes in dependencies
depending on library versions.
Indeed. But the ghc release that
On 16 August 2012 03:38, Bryan O'Sullivan b...@serpentine.com wrote:
Hi, folks -
I'm sure we are all familiar with the phrase cabal dependency hell at this
point, as the number of projects on Hackage that are intended to hack around
the problem slowly grows.
I am currently undergoing a
On Wed, Aug 15, 2012 at 9:19 PM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
On 16 August 2012 08:55, Brandon Allbery allber...@gmail.com wrote:
Indeed. But the ghc release that split up base broke cabalised packages
with no warning to users until they failed to compile. Upper
On Wed, Aug 15, 2012 at 11:02 PM, MightyByte mightyb...@gmail.com wrote:
be to add a flag to Cabal/cabal-install that would cause it to ignore
upper bounds. (Frankly, I think it would also be great if
Ignore, or at least treat them as being like flags... if the versions don't
converge with
On Thu, Aug 16, 2012 at 5:38 AM, Conrad Parker con...@metadecks.org wrote:
On 16 August 2012 03:38, Bryan O'Sullivan b...@serpentine.com wrote:
Hi, folks -
I'm sure we are all familiar with the phrase cabal dependency hell at
this
point, as the number of projects on Hackage that are
58 matches
Mail list logo
