Hi librarians, I'd like to propose a an extension to Cabal's dependency description syntax. Cabal currently supports version range descriptions using the unary operators >, >=, <, <=, ==, and binary operators && and ||. This can lead to rather awkward descriptions of common version ranges, for example, base >= 1 && < 2 and could lead to subtle errors like base > 1 && < 2 or base >= 1 && <= 2 I therefore propose two extensions. Both are just syntactic sugar. (1) Wildcards: 1.* ~~> >= 1 && < 2 in general m.n.o.* ~~> >= m.n.o && < m.n.(o+1) Note, that the translation is not ">= 1.0 && < 2", because that would exclude version "1", as [1] < [1,0] == True. (2) Ranges: 1 - 2.1 ~~> >= 1 && <= 2.1 in general m - n ~~> >= m && <= n If the upper limit is supposed to be exclusive, this can be combined with (1): 1 - 2.0.* ~~> >= 1 && < 2.1 A possible alternatve syntax (subsuming both (1) and (2)) could be: [1, 2.1] ~~> >= 1 && <= 2.1 [1, 2.1) ~~> >= 1 && < 2.1 Although this syntax is closer to mathematical notation, I prefer the former for it is more explicit and more similar to common conventions used in other languages/package systems (an less scary scary to non-math-aficiados). I'd like include this into Cabal-1.2 which is scheduled with the next ghc release, so it can fearlessly be used when getting packages ready for GC 6.8.1. Please comment/vote. Thanks, / Thomas
Thomas Schilling wrote:
(1) Wildcards:
1.* ~~> >= 1 && < 2
in general
m.n.o.* ~~> >= m.n.o && < m.n.(o+1)
I like this.
(2) Ranges:
1 - 2.1 ~~> >= 1 && <= 2.1
in general
m - n ~~> >= m && <= n
If the upper limit is supposed to be exclusive, this can be combined with (1):
1 - 2.0.* ~~> >= 1 && < 2.1
I like this, too, though maybe "to" instead of "-" would be a more readable token to use.
A possible alternatve syntax (subsuming both (1) and (2)) could be:
[1, 2.1] ~~> >= 1 && <= 2.1 [1, 2.1) ~~> >= 1 && < 2.1
This is too prone to fencepost errors due to the ease of getting the
parens wrong. Also, interval notation isn't widely enough used that
people will readily remember which kind of paren means what.
On Mon, 2007-09-24 at 21:36 +0100, Neil Mitchell wrote:
Hi
m.n.o.* ~~> >= m.n.o && < m.n.(o+1)
I like this.
Me too.
m - n ~~> >= m && <= n
I would much prefer m .. n as the syntax, as that is the syntax for ranges in Haskell.
Right, that's another option. Though, I'm not sure how that looks with dots in version. For comparision: Build-depends: base 1.1 to 2.1.*, filepath 1.1 to 1.* Build-depends: base 1.1 .. 2.1.*, filepath 1.1 .. 1.* Build-depends: base 1.1 - 2.1.*, filepath 1.1 - 1.* Build-depends: base [1.1, 2.2), filepath [1.1, 2) Spaces would be recommended (but not required) in any case. / Thomas
In message <404396ef0709241336n1fd188dax119feab0f71ac542@mail.gmail.com> "Neil
Mitchell"
Hi
m.n.o.* ~~> >= m.n.o && < m.n.(o+1)
I like this.
Me too.
m - n ~~> >= m && <= n
I would much prefer m .. n as the syntax, as that is the syntax for ranges in Haskell.
True, but it looks horrible with version numbers since they're full of '.'s: 1.2.3..4.5.6 ? I guess with our ReadP-based parser that's not ambiguous without whitespace but it's not nice. Duncan
On Mon, Sep 24, 2007 at 09:53:16PM +0200, Thomas Schilling wrote:
can lead to rather awkward descriptions of common version ranges, for example,
base >= 1 && < 2
I don't think anything more is needed, but...
(1) Wildcards:
1.* ~~> >= 1 && < 2
in general
m.n.o.* ~~> >= m.n.o && < m.n.(o+1)
I have no objections to this.
Note, that the translation is not ">= 1.0 && < 2", because that would exclude version "1", as [1] < [1,0] == True.
I'm not convinced that that isn't a bug.
(2) Ranges:
1 - 2.1 ~~> >= 1 && <= 2.1
I don't like that. I don't think someone writing that means to not include 2.1.0.0.1.
If the upper limit is supposed to be exclusive, this can be combined with (1):
1 - 2.0.* ~~> >= 1 && < 2.1
This reads very oddly to me.
I'd like include this into Cabal-1.2 which is scheduled with the next ghc release, so it can fearlessly be used when getting packages ready for GC 6.8.1.
I'd prefer we had more time to consider the syntax, as we don't want to be stuck with supporting whatever we come up with in the eleventh hour. Thanks Ian
On Mon, 2007-09-24 at 22:02 +0100, Ian Lynagh wrote:
On Mon, Sep 24, 2007 at 09:53:16PM +0200, Thomas Schilling wrote:
can lead to rather awkward descriptions of common version ranges, for example,
base >= 1 && < 2
I don't think anything more is needed, but...
(1) Wildcards:
1.* ~~> >= 1 && < 2
in general
m.n.o.* ~~> >= m.n.o && < m.n.(o+1)
I have no objections to this.
Note, that the translation is not ">= 1.0 && < 2", because that would exclude version "1", as [1] < [1,0] == True.
I'm not convinced that that isn't a bug.
Ack, me neither.
(2) Ranges:
1 - 2.1 ~~> >= 1 && <= 2.1
I don't like that. I don't think someone writing that means to not include 2.1.0.0.1.
Well, this leads to the issue if versioning schemes make promises about compatibility, and if so, whether Cabal should deal with those. For example, using the common scheme major.minor.patch-level Cabal should not use "foo 2.1" to satisfy "foo >= 1" as it might be (and likely is) incompatible. But it should always use "foo 1.2.3" to satisfy dependency "foo 1.2", but not necessarily "foo 1.4". We could allow giving semantics to versioning schemes like this, but I am neither sure what the details should be, nor if this would really be worth it. As a compromise, this special case could be disallowed, by forcing the pattern m - n.* ( or: m .. n.* ) but I guess that this would seem like an unnecessary restriction.
If the upper limit is supposed to be exclusive, this can be combined with (1):
1 - 2.0.* ~~> >= 1 && < 2.1
This reads very oddly to me.
I'd like include this into Cabal-1.2 which is scheduled with the next ghc release, so it can fearlessly be used when getting packages ready for GC 6.8.1.
I'd prefer we had more time to consider the syntax, as we don't want to be stuck with supporting whatever we come up with in the eleventh hour.
Fair enough. If people agree that it's not that useful or can't easily agree on what it should look like, I will not push it. I think at least (1) is uncontroversial and (2) would be a nice-to-have for the 'base' package. /Thomas
participants (5)
-
Bryan O'Sullivan -
Duncan Coutts -
Ian Lynagh -
Neil Mitchell -
Thomas Schilling