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 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
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. T
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 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 r
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, some
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 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 n
Chris
-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
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 bur
ehalf Of Erik Hesselink
> 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.
>
&
On 15/08/2012 21:44, Johan Tibell wrote:
On Wed, Aug 15, 2012 at 1:02 PM, Brandon Allbery 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
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
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 uppe
cool.)
Chris
-Original 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 frie
On Sat, Aug 18, 2012 at 3:57 AM, David Feuer 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 actually used.
This
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 constra
On Thu, Aug 16, 2012 at 9:53 AM, Felipe Almeida Lessa
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,
incompatibility can only arise
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
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:
ht
On Fri, Aug 17, 2012 at 4:35 PM, Bryan O'Sullivan wrote:
> 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
> dependencies" is de
On Aug 18, 2012, at 12:35 AM, "Bryan O'Sullivan" 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 across a
> large
On Fri, Aug 17, 2012 at 12:34 PM, MigMit 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 work well,
because
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.
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
wrote:
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 wrote:
> Brent Yorgey wrote:
>
>> Yitzchak Gale wrote:
>>
>>> For actively maintained packages, I think the
>
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 be
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 re
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 3:38 PM, Bryan O'Sullivan 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, agree. Here is my a
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 maintai
On Wed, Aug 15, 2012 at 9:38 PM, Bryan O'Sullivan wrote:
> 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 and install a
supp
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 a
On Thu, Aug 16, 2012 at 10:01 AM, Chris Smith wrote:
> Twan van Laarhoven 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-ri
y author. It's impossible 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
Datum: 16. 8. 2012
Předmět: Re: [Haskell-cafe] Platform Versioning Policy: uppe
On 16 August 2012 20:50, Ketil Malde wrote:
> "Bryan O'Sullivan" 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.
>
> A
Twan van Laarhoven 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
could be high ris
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 "i
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 kno
"Bryan O'Sullivan" 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 not always clear
Hi,
Am Mittwoch, den 15.08.2012, 12:38 -0700 schrieb Bryan O'Sullivan:
> 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.
as a Debian pa
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 o
On Thu, Aug 16, 2012 at 5:38 AM, Conrad Parker wrote:
> On 16 August 2012 03:38, 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 of projects on Hackage that are intended to hack
> around
> > t
On Wed, Aug 15, 2012 at 11:02 PM, MightyByte 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 them, start relaxin
On Wed, Aug 15, 2012 at 9:19 PM, Ivan Lazar Miljenovic
wrote:
> On 16 August 2012 08:55, Brandon Allbery wrote:
>> Indeed. But the ghc release that split up base broke cabalised packages
>> with no warning to users until they failed to compile. Upper bounds were
>> put in place to avoid that ki
On 16 August 2012 03:38, 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 of projects on Hackage that are intended to hack around
> the problem slowly grows.
>
> I am currently undergoing a fresh visit to
On 16 August 2012 08:55, Brandon Allbery wrote:
> On Wed, Aug 15, 2012 at 6:46 PM, Carter Schonwald
> 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 package
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
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 intend
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 han
On Wed, Aug 15, 2012 at 4:44 PM, Johan Tibell wrote:
> On Wed, Aug 15, 2012 at 1:02 PM, Brandon Allbery
> 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 ha
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 n
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 d
> 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 wrote:
> On Wed, Aug
On Wed, Aug 15, 2012 at 1:50 PM, David Thomas wrote:
> 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 adds complexity, but
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" wrote:
> On Wed, Aug 15, 2012 at 1:02 PM, Brandon Allbery
>
On Wed, Aug 15, 2012 at 1:02 PM, Brandon Allbery 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 know more), but
On Wed, Aug 15, 2012 at 1:02 PM, Brandon Allbery wrote:
>
> 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; didn't I say as mu
On Wed, Aug 15, 2012 at 3:57 PM, Johan Tibell wrote:
> On Wed, Aug 15, 2012 at 12:38 PM, Bryan O'Sullivan
> 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 ne
On Wed, Aug 15, 2012 at 12:38 PM, Bryan O'Sullivan 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 argument precisely cap
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 fresh visit to that unhappy realm, as I try to
rebuild some of my packages to
60 matches
Mail list logo
