[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
On Sun, 2007-10-21 at 23:42 +0200, Udo Stenzel wrote: > Duncan Coutts wrote: > > You can hack the .cabal file further to make it work in your situation, > > but I don't suggest that's a great long term solution. If you wanted to > > hack it you'd change it to just: > > > > build-depends: base, bytestring >= 0.9 > > > > without any 'if' or flags and without cpp-options: -DBYTESTRING_IN_BASE. > > Exactly what I did, and I consider that a crock, not a solution. I agree, that's what I said. > > The solution we're using at the moment is to use the separate bytestring > > package with ghc-6.4 and ghc-6.8 and to use the version of the > > bytestring code in base-2.x for ghc-6.6.x. That's what the newest > > versions of zlib, bzlib, iconv, binary, tar etc do. They all work with > > ghc-6.4, 6.6 and 6.8 (using Cabal-1.2.x). > > IOW, on GHC 6.6 I'm stuck with bytestring-0.8 and no package that > expects bytestring >= 0.9 will work unless it contains an ugly > workaround (an #ifdef). Unless my memory is failing me, that was not a > design objective of cabal. Indeed. That was not a design objective. However it's not something Cabal can change, it's a property of the underlying Haskell implementations. Currently it is not possible for a program to use two packages that have overlapping exposed modules. Also, it is essentially impossible at the moment to upgrade the base library on an existing ghc installation. These two facts together are why ghc-6.6 users are stuck with the implementations provided by base-2.x and cannot overlay things on top. It is also the motivation for breaking up the base package into smaller pieces which can be upgraded independently. (The base package itself will still not be easily upgradable but the other packages that were split out do become upgradable). > > What kind of change are you suggesting? > > > > We have to support base 2.x because that is the versions of base that > > come with ghc-6.6.x. We cannot sensibly install the separate bytestring > > package with ghc-6.6.x because it would clash with the base package > > there. We cannot easily upgrade base in existing installations of ghc > > because ghc is just not designed with that in mind at the moment. > > I'm suggesting to pretend that base never included ByteString, to have > an empty bytestring-0.8 package for GHC-6.6 (that just copies the > configuration of base) and to have bytestring > 0.8 fix the > configuration of base for GHC-6.6. GHC-6.6 is broken, and I'm > suggesting to fix it instead of accepting the breakage. I see why it's an attractive solution but I just don't think it is practical. We cannot go changing existing installations just like that. For one thing it's only possible for root users. For another one is not supposed to modify packages managed by the system package manger. We'd never get everyone to change. > If this was the right time for grand visions, I'd propose a feature > comparable to Provides: and Replaces: of Debian's apt, maybe combined > with packages that re-export modules and a better mechanism (read: any > mechanism) to resolve conflicts between packages. base may not be > upgradeable, but parts of it are. Oh, and I think multiple packages > providing the same modules and then causing conflicts is just a bad > idea, unless of of them took precedence. I agree, any of these things would be great. At the moment none of them are implemented (and they cannot be implemented in Cabal without corresponding support from the Haskell implementations). > > The right thing to do is to use the > > latest Cabal-1.2.x with whichever version of ghc you happen to have and > > not to use a hacked version of base. > > So the API of ByteString 0.8 is now fixed and nothing is allowed to > depend on anything newer, and that will be the case for at least the > next 2 years (until GHC 6.8 trickles down into Linux distributions in > actual use). Correct? Right. In practise that's not too bad since the public api of bytestring hardly changed. The internal changes only affect extension packages that use the internal api, things like binary. > Unless I need recent developments. Then I just copy the Data/ByteString > tree into my project directory... Funnily enough that's the only thing that will work, because ghc allows local modules to mask ones from a package like base, but not for modules from two used packages to overlap. There's not a lot Cabal can do to work around that. > > There is no need to upgrade > > immediately to ghc-6.8, in fact at the moment that'd make the situation > > worse since most packages need tweaks to work with it. > > And does that feel right to you? Should they actually need tweaks? No. I'd have preferred a better solution. Cabal configurations were not designed with this purpose in mind. You listed several better solutions. However the base breakup went ahead without any of them in place. The only currently implemented solution is to take advantage of configurations. A
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
(moving to haskell-cafe) On Sun, 2007-10-21 at 14:55 +0200, Udo Stenzel wrote: > Duncan Coutts wrote: > > New tarball releases of Cabal-1.2.1, bytestring-0.9, binary-0.4.1, tar > > and others (zlib, bzlib, iconv) will appear on hackage in the next few > > days. > > I just tried one of them, iconv. First it wants a recent cabal; that's > fine, I installed the darcs version. Then I get this: > > | Codec/Text/IConv.hs:64:17: > | Could not find module `Data.ByteString': > | it is a member of package bytestring-0.9, which is hidden > > Okay, it obviously tries to be smart, but doesn't know that I upgraded > to a separate ByteString library. Right. > So I take out the gunk about 'flag(bytestring-in-base)' and try again: > | Setup: At least the following dependencies are missing: > | base <2.0||>=2.2 > > Of course that was to be expected, since I have base-2.0 hacked to not > get in conflict with bytestring-0.9, and you (Duncan) couldn't possibly > anticipate this (or could you?). Right. It expects that if you have base >= 2.0 && < 2.2 then that version of base exports Data.ByteString. That's not an unreasonable assumption I think. You can hack the .cabal file further to make it work in your situation, but I don't suggest that's a great long term solution. If you wanted to hack it you'd change it to just: build-depends: base, bytestring >= 0.9 without any 'if' or flags and without cpp-options: -DBYTESTRING_IN_BASE. > Now what am I supposed to do? Give my messed up base a new version > number? (Which one?) Rewrite every single cabal file, hoping that > they never become Turing complete turning the exercise into a reverse > engineering fest rivaling the ICFP contest? Bite the bullet and > install GHC from darcs? So you've changed the API of base-2.1.1 so that will break packages that expect that they know what the api of base-2.1.1 actually is. You can either hack the .cabal files of things you try to install (which would be a pain, I don't recommend it) or you could revert your changes to your base package. > For the time being, I'll go with 'ghc --make'. And I think that cabal > configurations are an exceptionally bad idea carried to perfection. Don't get me wrong, I'm not claiming that the changes in what is in and what is out of the base package could not have been handled better. Configurations just happen to be one mechanism that we have available now to enable packages to build with various versions of the base package. The other alternative seemed to be that they'd only work with an old or a new version but not both. There are plenty of things that we could have done better to make the base changes less disruptive but I really don't think you can blame configurations for that or for adding to that problem. If we had made different decisions at various points we would not need configurations for this purpose right now. We'd still need configurations for other things. Configurations serve other purposes too. They're not just for managing the mess over moving modules between packages. They're generally to allow changes in the way a package is built depending on the environment in which the package is built to reduce the need for non-portable configure scripts and wadges of fragile code in Setup.hs files. > They make things worse, not better. (And that's just GHC 6.6... I don't > want to even think about what happens on Hugs, JHC and YHC.) It's mostly orthogonal to the Haskell implementation since the base package is shared by all Haskell implementations. > What would it take to talk you into giving up on supporting the broken > base-2.0 and incorporating a patch to unbreak it into the bytestring > setup? Can I stop the insanity by simply writing that patch? What kind of change are you suggesting? We have to support base 2.x because that is the versions of base that come with ghc-6.6.x. We cannot sensibly install the separate bytestring package with ghc-6.6.x because it would clash with the base package there. We cannot easily upgrade base in existing installations of ghc because ghc is just not designed with that in mind at the moment. The solution we're using at the moment is to use the separate bytestring package with ghc-6.4 and ghc-6.8 and to use the version of the bytestring code in base-2.x for ghc-6.6.x. That's what the newest versions of zlib, bzlib, iconv, binary, tar etc do. They all work with ghc-6.4, 6.6 and 6.8 (using Cabal-1.2.x). > > So all will not be plain sailing for the first few weeks after > > ghc-6.8 comes out as maintainers update their packages. People will have > > to be patient and/or stick to ghc-6.6 for a bit. > > Okay, so now we have *three* almost-stable versions of GHC in wide > circulation, all of them broken in different ways with respect to cabal > packages. I feel tears welling up... So far this weekend I've uploaded to hackage: Cabal-1.2.1, bytestring-0.9, unix-compat-0.1.1, tar-0.1.1 and Kolmodin uploaded binary-0.4.1.
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Daniel McAllansmith <[EMAIL PROTECTED]> writes: >> There are other reasons for a version bump than breaking compatibility. > Technical reasons? Well - say I refactor everything, and use algorithms with different run-time complexities, and possibly introduce different bugs than the ones the applications have come to rely on/work around. Even if the interface is type-level compatible, a conservative application would still prefer to link with the old version. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
On Thursday 18 October 2007 21:15, you wrote: > Daniel McAllansmith <[EMAIL PROTECTED]> writes: > > 3. Otherwise, major.minor MUST remain the same (other version components > > MAY change). > > Is it an option to say SHOULD rather than MUST here? Of course, SHOULD is an option just like MAY is. But both SHOULD and MAY reduce what you can reliably infer from a version number in the same way. If the rule is SHOULD or MAY, and the freedom is exercised, compatible versions of a package will differ in major[.minor] and dependent packages will be unable to benefit from their release. You'll need more maintenance work on package dependencies if you want to use the latest and greatest versions. In a similar way, if packages are being retained for a 'long time' to ensure dependent packages remain buildable, you are losing garbage collection opportunities. I'm pretty certain SHOULD will be far more socially acceptable than MUST. I can appreciate the fact that people are accustomed to incrementing version numbers in liberal ways. But if you look at version numbers dispassionately in the context of "The goal of a versioning system is to inform clients of a package of changes to that package that might affect them..." MUST seems a better choice. Maybe the Right Way of informing clients is full-on metadata and typing of packages and maybe we'll have that soon, so maybe a socially acceptable, weaker versioning scheme is acceptable. > There are > other reasons for a version bump than breaking compatibility. Technical reasons? In some cases a major bump would just be devolving to a minor bump. Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Ross Paterson wrote: On Wed, Oct 17, 2007 at 12:54:12PM +0100, Simon Marlow wrote: I've written down the proposed policy for versioning here: http://haskell.org/haskellwiki/Package_versioning_policy It turned out there was a previous page written by Bulat that contained essentially this policy, but it wasn't linked from anywhere which explains why it was overlooked. I took the liberty of rewriting the text. You wrote: A client that wants to specify that they depend on a particular version of the API can specify a particular A.B.C and be sure of getting that API only. For example, build-depends: mypkg-2.1.1 Are you proposing an extension along the lines of that proposed by Thomas (and Bulat, and others), i.e. this would be equivalent to build-depends: mypkg >= 2.1.1 && < 2.1.2 ? Yes, I should have mentioned that, thanks. I'll update the page shortly with this suggestion and others. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Daniel McAllansmith <[EMAIL PROTECTED]> writes: > 3. Otherwise, major.minor MUST remain the same (other version components MAY > change). Is it an option to say SHOULD rather than MUST here? There are other reasons for a version bump than breaking compatibility. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
On Thursday 18 October 2007 00:54, Simon Marlow wrote: > I've written down the proposed policy for versioning here: > >http://haskell.org/haskellwiki/Package_versioning_policy Is there technical reason for the major version number to consist of 2 components? Why not 3, 17 or (my preference) 1? Using major.minor instead of A.B.C, and interpreting MUST, SHOULD, MAY as specified by whatever RFC it is that specifies them, I'd write the change rules as: 1. If any entity was removed, or the types of any entities or the definitions of datatypes or classes were changed, or instances were added or removed, then the new major MUST be greater than the previous major (other version components MAY change). 2. Otherwise, if only new bindings, types or classes were added to the interface, then major MUST remain the same and the new minor MUST be greater than the old minor (other version components MAY change). 3. Otherwise, major.minor MUST remain the same (other version components MAY change). Why? - It gives the reader of the version numbers more information, which in turn may allow hackage to do more automated enforcement/testing/upgrading. - To safely specify dependencies you must use an upperbound of the next major version. The stricter change rules make it less likely that a package will miss out on the use of a new version of a dependency that is actually compatible but had it's version bumped anyway. The proposal isn't clear on whether this is allowed or not, but I think sets of version bounds are needed. Using A.B.C <==> major.minor.patch and interval notation for brevity: build-depends: foo [2.1, 3) U [3.3, 3.4) Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
On Wed, Oct 17, 2007 at 12:54:12PM +0100, Simon Marlow wrote: > I've written down the proposed policy for versioning here: > > http://haskell.org/haskellwiki/Package_versioning_policy > > It turned out there was a previous page written by Bulat that contained > essentially this policy, but it wasn't linked from anywhere which explains > why it was overlooked. I took the liberty of rewriting the text. You wrote: > A client that wants to specify that they depend on a particular version > of the API can specify a particular A.B.C and be sure of getting that > API only. For example, build-depends: mypkg-2.1.1 Are you proposing an extension along the lines of that proposed by Thomas (and Bulat, and others), i.e. this would be equivalent to build-depends: mypkg >= 2.1.1 && < 2.1.2 ? The current syntax of mypkg == 2.1.1 would match the initial release but not subsequent patch releases. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
On Wed, Oct 17, 2007 at 12:54:12PM +0100, Simon Marlow wrote: > I've written down the proposed policy for versioning here: > > http://haskell.org/haskellwiki/Package_versioning_policy This says: If [...] instances were added or removed, then the new A.B must be greater than the previous A.B. This presumably includes changing module imports, or depending on a newer version of a package, which results in the visible instances changing? I think this should be spelt out in the policy. The example: build-depends: mypkg == 2.1.1 should be: build-depends: mypkg >= 2.1.1, mypkg < 2.1.2 with the current dependency syntax/semantics. Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
I've written down the proposed policy for versioning here: http://haskell.org/haskellwiki/Package_versioning_policy It turned out there was a previous page written by Bulat that contained essentially this policy, but it wasn't linked from anywhere which explains why it was overlooked. I took the liberty of rewriting the text. I took into account Ross's suggestions that the major version should have two components, and that we need to be more precise about what it means to extend an API. After a round of editing, we can start to link to this page from everywhere, and start migrating packages to this scheme where necessary. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Hi > > In general, if it compiles and type checks, it will work. It is rare > > that an interface stays sufficiently similar that the thing compiles, > > but then crashes at runtime. Given that, shouldn't the tested versions > > be something a machine figures out - rather than something each > > library author has to tend to with every new release of every other > > library in hackage? > > The only reasonable way we have to test whether a package compiles with a > new version of a dependency is to try compiling it. To do anything else > would be duplicating what the compiler does, and risks getting it wrong. Agreed - that's what I meant by checking it. Ideally with multiple compilers. > But you're right that tools could help a lot: for example, after a base > version bump, Hackage could try to build all its packages against the new > base to figure out which ones need source code modifications and which can > probably just have their .cabal files tweaked to allow the new version. > Hackage could tentatively fix the .cabal files itself and/or contact the > maintainer. Even better, after any new package release hackage could compute all packages which depend on that one and try them. That way you can always guarantee that every hackage package will work with the latest hackage dependencies. Another way of saying this is that every package on hackage should compile out the box with cabal-install on a fresh system. > We'll really need some tool to analyse API changes too, otherwise API > versioning is too error-prone. Anyone like to tackle this? It shouldn't > be too hard using the GHC API.. You can also do it with haddock and the --hoogle flag, to some extent. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Neil Mitchell wrote: Hi I agree. >= 1.0 isn't viable in the long term. Rather, a specific list, or bounded range of tested versions seems likely to be more robust. In general, if it compiles and type checks, it will work. It is rare that an interface stays sufficiently similar that the thing compiles, but then crashes at runtime. Given that, shouldn't the tested versions be something a machine figures out - rather than something each library author has to tend to with every new release of every other library in hackage? The only reasonable way we have to test whether a package compiles with a new version of a dependency is to try compiling it. To do anything else would be duplicating what the compiler does, and risks getting it wrong. But you're right that tools could help a lot: for example, after a base version bump, Hackage could try to build all its packages against the new base to figure out which ones need source code modifications and which can probably just have their .cabal files tweaked to allow the new version. Hackage could tentatively fix the .cabal files itself and/or contact the maintainer. We'll really need some tool to analyse API changes too, otherwise API versioning is too error-prone. Anyone like to tackle this? It shouldn't be too hard using the GHC API.. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
[would it be possible to pick a single list to discuss this on please, so there is no danger of some people missing some subthreads if they aren't on all the lists, or getting messages 3 times if they are?] On Tue, Oct 16, 2007 at 01:08:49PM +0100, Simon Marlow wrote: > > 2. Precise dependencies. While not directly related to this, I have the impression some people want precise dependencies so that things work properly when multiple versions of a library are installed. Personally I'm not a fan of that, as if I have package foo: module Foo where data T package bar: module Bar where bar :: T package baz: module Baz where baz :: T -> () then baz bar might be a type error if I have multiple versions of foo installed and bar and baz have been compiled against different versions. Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Following is a summary of my thoughts on the matter, in large part so I can figure out what I'm thinking... apologies if it's a bit of a ramble. All comments welcome. Basically - version numbering which differs from Simon's proposal - precise dependencies, I think the same as Simon is proposing - 'permanent' availability of compatible package versions - never a need to update working cabal files - a cabal file installs exactly one version of a package 1) Package version numbers are of the form x.y.z 2) There are version-segment ordering functions cmpX, cmpY, and cmpZ. cmpX and cmpY are globally defined and operate over non-negative integers. Perhaps cmpZ is globally defined, or could be defined per package, or be lexicographic, or... something else. cmpZ could even be a partial ordering I suppose. 3) A cabal file specifies how to build a single version of a package. name: foo version: 2.12.5 This cabal file will build version 2.12.5 of package foo. 4) The dependencies in a cabal file define baseline versions of required packages. depends: bar [3.4] baz [1.2.6, 3] Version 2.12.5 of foo requires a version of bar that is API-compatible with 3.4.0 and a version of baz that is API-compatible with 1.2.6 _or_ API-compatible with 3.0.0. Note that this doesn't imply that baz 3.0.0 is API-compatible with baz 1.2.6 (by definition it is not), it implies that foo is using a subset of the intersection of those two baz APIs. Note that baz 2.y.z would not satisfy the dependency. Perhaps a function was removed with the bump to 2 and restored only with the bump to 3. 5) Package version numbers encode whether one version of a package is API-compatible with another version of the package. Given two versions x.y.z and i.j.k of a package: - x == i && y == j ==> x.y.z is API-identical (hence API-compatible) with i.j.k, cmpZ can be used to determine preferred version - x == i && y > j ==> x.y.z is API-compatible with i.j.k, it has undergone compatibility-preserving changes, x.y.z is preferred to i.j.k - x > i ==> x.y.z is not API-compatible with i.j.k, it has undergone non-compatibility-preserving changes - otherwise ==> x.y.z is not API-compatible with i.j.k, it is a lower version that has less functionality 6) A compatibility-preserving change is generally a change which just adds to the API. Ross Paterson points out adding extra data constructors or instances may not be compatibility-preserving. A non-compatibility-preserving change is generally a change which includes the removal of some part of the API. It might also include changes which leave the API unmodified but significantly degrade usability, e.g. worse time or space performance. 7) Once a version of a package is building successfully it remains available for a 'long time'. If sufficient versions of a package remain available then API-compatible versions of required packages are always available, so the building of packages should never break. An uploaded cabal file should never need to be changed, regardless of what happens to the packages it depends upon. 8) If a version of a package is discovered to have security flaws or serious bugs it should remain available in a quarantined state until a fixed API-compatible version is available. 9) Something (hackage?) could enforce adherence to version numbering policy. At the least any new version uploaded that claims to be API-compatible can be test compiled against packages which depend on it. Something (hackage?) could assist package maintainers in releasing a new version of their package with updated dependency information. Hackage could attempt to compile against non API-compatible versions and report the outcome, for example foo 2.12.5 compiles with the new baz 3.0.0 but not the latest baz 2.y.z Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: [Haskell] Re: Trying to install binary-0.4
On Tue, 2007-10-16 at 14:01 +0100, Bayley, Alistair wrote: > > From: Simon Marlow [mailto:[EMAIL PROTECTED] > > > > The lexicographical ordering would make 10.0 > 9.3. In > > general, A.B > C.D > > iff A > C or A == C && B > D. When we say the "latest" > > version we mean > > "greatest", implying that version numbers increase with time. > > Does that help? > > > Sort of. It's what I'd expect from a sensible version comparison. It's > just not something I'd ever choose to call lexicographic ordering. IMO, > lexicographgic ordering is a basic string comparision so e.g. > > max "10.0" "9.3" = "9.3" > > I'd call what you're doing numeric ordering. Does it have a better name, > like version-number-ordering, or section-number-ordering (e.g. Section > 3.2.5, Section 3.2.6)? It's lexicographic ordering on the list of numbers, not on the string representation. ie it's [10, 0] > [9, 3] not "10.0" > "9.3" Internally we represent version numbers as lists of integers and use the default Ord instance. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Neil Mitchell wrote: Hi I agree. >= 1.0 isn't viable in the long term. Rather, a specific list, or bounded range of tested versions seems likely to be more robust. In general, if it compiles and type checks, it will work. It is rare that an interface stays sufficiently similar that the thing compiles, but then crashes at runtime. True.. GoboLinux's package system records the exact set of versions something compiles with (just for reference), and uses min version bounds (and max bounds where needed) for dependencies. It's always possible for Haskell library implementation-bug-fixes to change relied-on behavior, as discussed in the original ECT description. I agree that compiling and type-checking is a pretty good sign of working. Passing tests (e.g. QuickCheck) could be tested too, where available. If optimizations and unsafePerformIO interact differently, different compiler versions could also affect whether something works correctly, but still compiles... But, the issue here is much more limited: we assume that there were some set of versions of these libraries that DID work, and, that every version of each library, on its own (or with only the libraries it depends on), works. So it might be valuable to record subjectively-working exact version sets, somewhere. Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Hi > I agree. >= 1.0 isn't viable in the long term. Rather, a specific list, > or bounded range of tested versions seems likely to be more robust. In general, if it compiles and type checks, it will work. It is rare that an interface stays sufficiently similar that the thing compiles, but then crashes at runtime. Given that, shouldn't the tested versions be something a machine figures out - rather than something each library author has to tend to with every new release of every other library in hackage? Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
simonmarhaskell: > Several good points have been raised in this thread, and while I might not > agree with everything, I think we can all agree on the goal: things > shouldn't break so often. > > So rather than keep replying to individual points, I'd like to make some > concrete proposals so we can make progress. > > 1. Document the version numbering policy. > > We should have done this earlier, but we didn't. The proposed policy, for > the sake of completeness is: x.y where: > > x changes ==> API changed > x constant but y changes ==> API extended only > x and y constant ==> API is identical > > further sub-versions may be added after the x.y, their meaning is > package-defined. Ordering on versions is lexicographic, given multiple > versions that satisfy a dependency Cabal will pick the latest. > > 2. Precise dependencies. > > As suggested by various people in this thread: we change the convention so > that dependencies must specify a single x.y API version, or a range of > versions with an upper bound. Cabal or Hackage can refuse to accept > packages that don't follow this convention (perhaps Hackage is a better > place to enforce it, and Cabal should just warn, I'm not sure). I agree. >= 1.0 isn't viable in the long term. Rather, a specific list, or bounded range of tested versions seems likely to be more robust. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Ross Paterson wrote: I would make "API extended only" a bit more precise: any module that uses explicit import lists will not be affected by the changes. So one can add classes, types and functions, but not instances (except where either the class or the type is new). okay You probably can't add data constructors or fields, and have to be careful with new methods. If they're exported and new members of existing classes/datatypes, then you can't add them, because they might be imported with "class/typename(..)". (right?) What about semantic changes to the API? Including, adding a default to a class method changes the default from 'undefined', which someone might have relied on as the default (although it seems unlikely). Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
On Tue, Oct 16, 2007 at 01:08:49PM +0100, Simon Marlow wrote: > So rather than keep replying to individual points, I'd like to make some > concrete proposals so we can make progress. > > 1. Document the version numbering policy. > > We should have done this earlier, but we didn't. The proposed policy, for > the sake of completeness is: x.y where: > > x changes ==> API changed > x constant but y changes ==> API extended only > x and y constant ==> API is identical > > further sub-versions may be added after the x.y, their meaning is > package-defined. This should be required for at least the GHC boot packages (and encouraged for others). I would make "API extended only" a bit more precise: any module that uses explicit import lists will not be affected by the changes. So one can add classes, types and functions, but not instances (except where either the class or the type is new). You probably can't add data constructors or fields, and have to be careful with new methods. I'd also prefer that major versions used two numbers, because that's common now, it supports the experimental versions 0.x apfelmus mentioned, and it makes it easier to leave room for development versions (possibly using an odd-even scheme). If you make your development repository available, and it contains API changes, you'll want its version number to have a larger major number. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
If the convention for modifying package versions of form x.y.z is: - increment z for bugfixes/changes that don't alter the interface - increment y for changes that consist solely of additions to the interface, parts of the interface may be marked as deprecated - increment x for changes that include removal of deprecated parts of the interface i like this, but i doubt it will catch on (see my reply to Simon's summary). The 'foo' package name is just an indicator of lineage. foo-2.xxx is not the same package as foo-1.xxx, it's interface is missing something that foo-1.xxx's interface provided. yes, that is the troublesome part. Dependencies of "foo" shouldn't appear in published cabal files. There is a case for their use in development where you are specifying that you want to depend on the very latest version of foo available, perhaps from darcs. When you publish that latest version number gets burned in, eg "foo-2.1.20071016". agreed, because of your point above. though i think we'll need to find a similarly convenient replacement.. or we'll be changing old cabal files forever. As for provides/expects and imported-modules instead, isn't that just an arbitrary line drawn in the granularity sand? Perhaps package versions could be expanded to include the type of every function they expose, plus more information to indicate which bugfix version of those functions is present. That's maybe the Right Way... and probably a lot of work. as with all type systems, there is a balance between preciseness, decidability, and useability. just adding an imported-modules: field would do no harm (like the exposed-modules: field, it should be inferred), but it would allow cabal to make better choices. in the context of the base split, or similar api refactorings, package names don't tell us much, package versions at best tell us that there is a problem (and may not even tell us that); if existing packages had an additional imported-modules: field, cabal could try to suggest alternative providers - in the current case, that would be the new base and its spin-off packages. then the user could just accept those alternatives, and be happy. claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
1. Document the version numbering policy. agreed. just making everybody's interpretation explicit has already exposed subtle differences, so documenting common ground will help. We should have done this earlier, but we didn't. The proposed policy, for the sake of completeness is: x.y where: x changes ==> API changed x constant but y changes ==> API extended only x and y constant ==> API is identical further sub-versions may be added after the x.y, their meaning is package-defined. Ordering on versions is lexicographic, given multiple versions that satisfy a dependency Cabal will pick the latest. referring to a haskell function to compute ordering, or to parse version strings into lists of numbers, might remove ambiguities here. for instance, some people use patch-levels as sub-versions, some use dates. also, compare Simon's (S) with Daniel's (D) version: | If the convention for modifying package versions of form x.y.z is: | - increment z for bugfixes/changes that don't alter the interface | - increment y for changes that consist solely of additions to the interface, |parts of the interface may be marked as deprecated | - increment x for changes that include removal of deprecated parts of the | interface version D gives us strictly more information from a version number: just from number differences, we can tell what kind of changes happened to the api. i like that. version S is closer to current practice, which is less informative but psychologically motivated:-) if one does a substantial rewrite without changing the api, or if one adds fundamentally new features without breaking backwards compatibility, one likes to bump the leading number (that is no doubt inspired by commercialism: paying customers are said to prefer higher version numbers, and to focus on new features). corollary: after fixing the version numbering policy (policies?), the implications on usage need to be investigated (sorting wrt dates? does a version number tell us anything about which version can stand in for which dependency?). 2. Precise dependencies. As suggested by various people in this thread: we change the convention so that dependencies must specify a single x.y API version, or a range of versions with an upper bound. Cabal or Hackage can refuse to accept packages that don't follow this convention (perhaps Hackage is a better place to enforce it, and Cabal should just warn, I'm not sure). Yes, earlier I argued that not specifying precise dependencies allows some packages to continue working even when dependencies change, and that having precise dependencies means that all packages are guaranteed to break when base is updated. However, I agree that specifying precise dependencies is ultimately the right thing, we'll get better errors when things break, agreed. please note, however, that this is likely to flush out issues that have so far been swiped under the carpet. this is a good thing, as it will lead to proposals for making cabal deal with these issues properly (replacing unspecified user complaints with concrete bugs and fixes). but it will increase the noise!-) claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: [Haskell] Re: Trying to install binary-0.4
On Oct 16, 2007, at 9:01 , Bayley, Alistair wrote: From: Simon Marlow [mailto:[EMAIL PROTECTED] The lexicographical ordering would make 10.0 > 9.3. In general, A.B > C.D iff A > C or A == C && B > D. When we say the "latest" version we mean "greatest", implying that version numbers increase with time. Does that help? Sort of. It's what I'd expect from a sensible version comparison. It's just not something I'd ever choose to call lexicographic ordering. IMO, lexicographgic ordering is a basic string comparision so e.g. max "10.0" "9.3" = "9.3" I'd call what you're doing numeric ordering. Does it have a better name, like version-number-ordering, or section-number-ordering (e.g. Section 3.2.5, Section 3.2.6)? "Lexicographic ordering", to me, means ordering by the collation sequence for individual characters. I'd call this multi-field numeric ordering with "." as the field separator. "Version number ordering" is a bit trickier: it's used by Linux/*BSD package systems that need to deal with versions like "1.2a3_4,1" (which in FreeBSD means package version 1.2a3 (which is defined by the package originator and usually means the alpha-3 release of version 1.2), FreeBSD package version 4 thereof, with an epoch of 1 to force higher sorting because at some point a new version was retracted (say, 1.2a4 was packaged, then turned out to have major bugs that caused a rollback to 1.2a3, so the epoch is bumped to indicate that this 1.2a3 is actually later than the 1.2a4). RPM and APT have similar mechanisms, although syntactically different. (I don't *think* we need to care about this. Unfortunately, while Cabal version numbers are fairly clearly only the upstream part of it, and defined such that we don't need to determine whether 1.2a4 sorts before or after 1.2 (a rat's nest pretty much every OS distribution packaging system needs to fight with), I can imagine Hackage needing something like an epoch to handle regressions while allowing cabal-install to do the right thing.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
On Oct 16, 2007, at 4:21 , Ketil Malde wrote: The major/minor scheme has worked nicely for .so for ages. i'm not so sure about that. it may be better than alternatives, but [..] Also, it sees a lot of testing, at least in current Linux distributions. The point is that the end-user experience is pretty good. Except it doesn't, quite; note how many packages have started embedding the version in the soname (e.g. foo-1.2.so.*). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Bayley, Alistair wrote: From: Simon Marlow [mailto:[EMAIL PROTECTED] The lexicographical ordering would make 10.0 > 9.3. In general, A.B > C.D iff A > C or A == C && B > D. When we say the "latest" version we mean "greatest", implying that version numbers increase with time. Does that help? Sort of. It's what I'd expect from a sensible version comparison. It's just not something I'd ever choose to call lexicographic ordering. IMO, lexicographgic ordering is a basic string comparision so e.g. max "10.0" "9.3" = "9.3" I'd call what you're doing numeric ordering. Does it have a better name, like version-number-ordering, or section-number-ordering (e.g. Section 3.2.5, Section 3.2.6)? I've heard it called lexicographical ordering before, but I'm happy to call it by whatever name induces the least confusion! Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: [Haskell] Re: Trying to install binary-0.4
> From: Simon Marlow [mailto:[EMAIL PROTECTED] > > The lexicographical ordering would make 10.0 > 9.3. In > general, A.B > C.D > iff A > C or A == C && B > D. When we say the "latest" > version we mean > "greatest", implying that version numbers increase with time. > Does that help? Sort of. It's what I'd expect from a sensible version comparison. It's just not something I'd ever choose to call lexicographic ordering. IMO, lexicographgic ordering is a basic string comparision so e.g. max "10.0" "9.3" = "9.3" I'd call what you're doing numeric ordering. Does it have a better name, like version-number-ordering, or section-number-ordering (e.g. Section 3.2.5, Section 3.2.6)? Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Bayley, Alistair wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Marlow x changes ==> API changed x constant but y changes ==> API extended only x and y constant ==> API is identical Ordering on versions is lexicographic, given multiple versions that satisfy a dependency Cabal will pick the latest. Just a minor point, but would mind explaining exactly what lexicographic ordering implies? It appears to me that e.g. version 9.3 of a package would be preferred over version 10.0. That strikes me as counter-intuitive. The lexicographical ordering would make 10.0 > 9.3. In general, A.B > C.D iff A > C or A == C && B > D. When we say the "latest" version we mean "greatest", implying that version numbers increase with time. Does that help? Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Simon Marlow wrote: Claus Reinke wrote: - if you provide a 'base' configuration that pulls in the stuff that used to be in base, the package will work I don't know of a way to do that. The name of the package is baked into the object files at compile time, so you can't use the same compiled module in more than one package. i've been wrong about this before, so check before you believe,-) but here is a hack i arrived at the last time we discussed this: [using time:Data.Time as a small example; ghc-6.6.1] 1. create, build, and install a package QTime, with default Setup.hs ... 2. create, build, and install a package Time2, with default Setup.hs ... 3. write and build a client module Ok, when I said above "I don't know a way to do that", I really meant there's no way to do it by modifying the package database alone, which I think is what Udo was after. Your scheme does work, and you have discovered how to make a package that re-exports modules from other packages (I made a similar discovery recently when looking into how to add support to Cabal for this). As you can see, it's rather cumbersome, in that you need an extra dummy package, and two stub modules for each module to be re-exported. Ah, I should add that due to technical limitations this scheme can't be used to make a base-2 that depends on base-3. Base is special in this respect, GHC only allows a single package called base to be linked into any given executable. The reason for this is that GHC can be independent of the version of the base package, and refer to it as just "base"; in theory it's possible to upgrade the base package independently of GHC. So we're restricted at the moment to providing only completely independent base-2 and base-3 in the same installation, and essentially that means having (at least) two copies of every package, one that depends on base-2 and one that depends on base-3. Perhaps we should revisit this decision, it would be better for GHC to depend explicitly on base-3, but allow a separate backwards-compatible base-2 that depends on base-3 to be installed alongside. OTOH, this will still lead to difficulties when you try to mix base-2 and base-3. Suppose that the Exception type changed, so that base-2 needs to provide its own version of Exception. The base-2:Exception will be incompatible with the base-3:Exception, and type errors will ensue if the two are mixed. If the base-3:Exception only added a constructor, then you could hide it in base-2 instead of defining a new type. However, if base-3 changed the type of a constructor, you're stuffed. Ah, I think we've discovered a use for the renaming feature that was removed in Haskell 1.3! Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
* Simon Marlow wrote: > further sub-versions may be added after the x.y, their meaning is > package-defined. Ordering on versions is lexicographic, given multiple > versions that satisfy a dependency Cabal will pick the latest. x.y.z should be ordered numerically, if possible. > As suggested by various people in this thread: we change the convention so > that dependencies must specify a single x.y API version, or a range of > versions with an upper bound. Cabal or Hackage can refuse to accept > packages that don't follow this convention (perhaps Hackage is a better > place to enforce it, and Cabal should just warn, I'm not sure). Ack. Hackage is a good place to reject. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: [Haskell] Re: Trying to install binary-0.4
On 10/16/07, Bayley, Alistair <[EMAIL PROTECTED]> wrote: > Just a minor point, but would mind explaining exactly what lexicographic > ordering implies? It appears to me that e.g. version 9.3 of a package > would be preferred over version 10.0. That strikes me as > counter-intuitive. I believe the intent is "lexicographic" in the sense that a version number is a dot-separated sequence of integers. So if you interpret "9.3" as [9, 3] and "10.0" as [10, 0], then Prelude> max [9, 3] [10, 0] [10,0] and Prelude> max [1, 9] [1, 10] [1,10] work in the expected way. Stuart ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Claus Reinke wrote: - if you provide a 'base' configuration that pulls in the stuff that used to be in base, the package will work I don't know of a way to do that. The name of the package is baked into the object files at compile time, so you can't use the same compiled module in more than one package. i've been wrong about this before, so check before you believe,-) but here is a hack i arrived at the last time we discussed this: [using time:Data.Time as a small example; ghc-6.6.1] 1. create, build, and install a package QTime, with default Setup.hs ... 2. create, build, and install a package Time2, with default Setup.hs ... 3. write and build a client module Ok, when I said above "I don't know a way to do that", I really meant there's no way to do it by modifying the package database alone, which I think is what Udo was after. Your scheme does work, and you have discovered how to make a package that re-exports modules from other packages (I made a similar discovery recently when looking into how to add support to Cabal for this). As you can see, it's rather cumbersome, in that you need an extra dummy package, and two stub modules for each module to be re-exported. One way to make this easier is to add a little extension to GHC, one that we've discussed before: module Data.Time (module Base1.Data.Time) where import "base-1.0" Data.Time as Base1.Data.Time the extension is the "base-1.0" package qualifier on the import, which GHC very nearly supports (only the syntax is missing). Now you don't need the dummy package, and only one stub module per module to be re-exported. Cabal could generate these automatically, given some appropriate syntax. Furthermore, this is better than doing something at the package level, because you're not stuck with module granularity, you can re-export just parts of a module, which is necessary if you're trying to recreate an old version of an API. I was going to propose this at some point. Comments? Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: [Haskell] Re: Trying to install binary-0.4
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Simon Marlow > >x changes ==> API changed >x constant but y changes ==> API extended only >x and y constant ==> API is identical > > Ordering on versions is lexicographic, given multiple > versions that satisfy a dependency Cabal will pick the latest. Just a minor point, but would mind explaining exactly what lexicographic ordering implies? It appears to me that e.g. version 9.3 of a package would be preferred over version 10.0. That strikes me as counter-intuitive. Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Several good points have been raised in this thread, and while I might not agree with everything, I think we can all agree on the goal: things shouldn't break so often. So rather than keep replying to individual points, I'd like to make some concrete proposals so we can make progress. 1. Document the version numbering policy. We should have done this earlier, but we didn't. The proposed policy, for the sake of completeness is: x.y where: x changes ==> API changed x constant but y changes ==> API extended only x and y constant ==> API is identical further sub-versions may be added after the x.y, their meaning is package-defined. Ordering on versions is lexicographic, given multiple versions that satisfy a dependency Cabal will pick the latest. 2. Precise dependencies. As suggested by various people in this thread: we change the convention so that dependencies must specify a single x.y API version, or a range of versions with an upper bound. Cabal or Hackage can refuse to accept packages that don't follow this convention (perhaps Hackage is a better place to enforce it, and Cabal should just warn, I'm not sure). Yes, earlier I argued that not specifying precise dependencies allows some packages to continue working even when dependencies change, and that having precise dependencies means that all packages are guaranteed to break when base is updated. However, I agree that specifying precise dependencies is ultimately the right thing, we'll get better errors when things break, There's lots more to discuss, but I think the above 2 proposals are a step in the right direction, agreed? Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
- if you provide a 'base' configuration that pulls in the stuff that used to be in base, the package will work I don't know of a way to do that. The name of the package is baked into the object files at compile time, so you can't use the same compiled module in more than one package. i've been wrong about this before, so check before you believe,-) but here is a hack i arrived at the last time we discussed this: [using time:Data.Time as a small example; ghc-6.6.1] 1. create, build, and install a package QTime, with default Setup.hs -- QTime.cabal Name: QTime Version: 0.1 Build-depends: base, time Exposed-modules: QTime.Data.Time -- QTime/Data/Time.hs module QTime.Data.Time(module Data.Time) where import Data.Time 2. create, build, and install a package Time2, with default Setup.hs -- Time2.cabal Name: Time2 Version: 0.1 Build-depends: base, QTime Exposed-modules: Data.Time -- Data/Time.hs module Data.Time(module QTime.Data.Time) where import QTime.Data.Time 3. write and build a client module -- Main.hs import Data.Time main = print =<< getCurrentTime $ ghc -hide-all-packages -package base Main.hs Main.hs:1:0: Failed to load interface for `Data.Time': it is a member of package Time2-0.1, which is hidden $ ghc -hide-all-packages -package base -package Time2 Main.hs $ ./main.exe 2007-10-16 11:09:05.859375 UTC $ rm main.exe Main.hi Main.o $ ghc -hide-all-packages -package base -package time Main.hs $ ./main.exe 2007-10-16 11:09:29.34375 UTC as i said, i've misinterpreted such symptoms before, but it seems to me that Time2's Data.Time acts as a drop-in replacement for time's Data.Time here. doesn't it? it is rather tedious, having to do something for every module in the package, twice (once to get a package-qualified name that differs from the original name, the second time to re-expose it under its original name), but that could be automated. and there would be an extra QBase package. but until cabal supports such renamings directly, it might be a workaround for the current base issue? claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
On Tuesday 16 October 2007 21:16, Simon Marlow wrote: > > - when GHC 6.8 comes out containing base-3, will it be possible to > > additionally install something calling base-2 with both being > > available to packages? > > In theory yes - the system was designed to allow this. In practice we've > never tried it, and base-2 might not compile unmodified with GHC 6.8. > > > - If so, will existing Cabal packages automatically pick up the > > compatible base-2 despite base-3 being available? > > Only if they specify an upper bound on the base dependency, which most > don't, but it's an easy change to make. It seems more sensible to me for dependencies to always have an upper bound of the next major version. foo-3.y.z won't satisfy foo-2.3.4. If it so happens that a package depends on the subset of foo's interface that was retained from foo-2.3.4 through to foo-3.0.0 then the dependency can be changed to foo-2.3.4,3.0.0 (modulo syntax) once it has been tested. If dependencies on foo often end up like this due to use of a distinct subset of the interface it's probably a good sign that foo is too coarse-grained. If a major version increment, by definition, implies a removal of functionality from a package then having no upper bound on the dependency pushes work out to the user that would be better done by the maintainer. With an upper bound users are still able to try and get the package going with a later version of a dependency if they want. Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Be happy: we're about 15 years ahead of the lisp guys. 'cabal install xmonad' works, for example. - not on windows (and since it is popular, it will seduce more good haskellers not to bother with windows compatibility.. :-( - from xmonad.cabal (version 0.3, from hackage): build-depends: base>=2.0, X11>=1.2.1, X11-extras>=0.3, mtl>=1.0, unix>=1.0 so, you guarantee that it will work with base-3.0, X11-2.0, X11-extras-1.0, mtl-2.0, unix-2.0. even though all of those will -if i now understand the versioning intentions correctly- lack features of the current versions? claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
"Claus Reinke" <[EMAIL PROTECTED]> writes: >> You need a way to specify "foo > 1.2 && foo < 2", which is a >> suggestion that was tossed around here recently. > but what does such a version range say? that i haven't tested any > versions outside the range (because they didn't exist when i wrote > my package)? or that i have, and know that later versions won't do? IMO, it says that it works with interface version 1, and needs some stuff from sublevel 2, and as long as the foo developers keep their end of the bargain, it will continue to work with new releases in the 1-series. For foo-2, the interface may change, and all bets are off. The dependency could be expressed more in a more succinct (albeit less flexible) manner with a different syntax (e.g. "foo-1.2"). > if that decision is based on version numbers alone, we need to > be specific about the meaning of version numbers in dependencies. Yes. > and if the major/minor scheme is to be interpreted as Simon > summarised, the only acceptable form of a dependency is an > explicit version range (the range of versions known to work). I'm happy with "expected to work". >> The major/minor scheme has worked nicely for .so for ages. > i'm not so sure about that. it may be better than alternatives, > but [..] Also, it sees a lot of testing, at least in current Linux distributions. The point is that the end-user experience is pretty good. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Udo Stenzel wrote: Simon Marlow wrote: So a package that depends on 'base' (with no upper version bound) *might* be broken in GHC 6.8.1, depending on which modules from base it actually uses. Let's look at the other options: - if we rename base, the package will *definitely* be broken - if the package specified an upper bound on its base dependency, it will *definitely* be broken - if you provide a 'base' configuration that pulls in the stuff that used to be in base, the package will work I don't know of a way to do that. The name of the package is baked into the object files at compile time, so you can't use the same compiled module in more than one package. I hate betting, but I'd like to know if... - it is okay to give GHC 6.4/6.6 a castrated configuration of the base libraries to remove the conflict with recent ByteString? Sure, that's what I suggested before. Moving modules of an existing package from 'exposed-modules' to 'hidden-modules' is safe (I wouldn't recommend removing them entirely). - when GHC 6.8 comes out containing base-3, will it be possible to additionally install something calling base-2 with both being available to packages? In theory yes - the system was designed to allow this. In practice we've never tried it, and base-2 might not compile unmodified with GHC 6.8. - If so, will existing Cabal packages automatically pick up the compatible base-2 despite base-3 being available? Only if they specify an upper bound on the base dependency, which most don't, but it's an easy change to make. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Daniel McAllansmith <[EMAIL PROTECTED]> writes: >>> I think what you're asking for is more than that: you want us to provide >>> base-1.0, base-2.0 and base-3.0 at the same time, so that old packages >>> continue to work without needing to be updated. Yes. >>> That is possible, but much more work for the maintainer. How much more work, really? If the dependencies of your library have similar backwards compatible support, you only have to keep track of backwards-incompatible changes to the compiler, and I think those are relatively few and far apart. >>> Ultimately when things settle down it might make sense to do this >>> kind of thing, but right now I think an easier approach is to just >>> fix packages when dependencies change, and to identify sets of >>> mutually-compatible packages (we've talked about doing this on >>> Hackage before). I'm surprised you think this is easier - There's an awful lot of possible version combinations, and for every library that breaks, there is - at least potentially - a lot of applications that needs updating. Many of those will be web orphans that some curious newbie will download and fail to get to work. (SOE, anybody? FiniteMap to Data.Map?) I think a library is more likely to be supported than an application, and likely to be supported by more and more competent developers. > I think it's a no-brainer that old versions of packages should remain > available for people to use for 'a long time'. If their dependencies are > specified properly they should continue building successfully as time passes. Amen. > Presumably it's not usually a problem if indirect package dependencies > require > incompatible versions of a package. If it is, I think this is a strong argument in favor of "package bundles" that are released and upgraded together as something resembling a standard library. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Don Stewart wrote: > stefanor: >> On Mon, Oct 15, 2007 at 10:57:48PM +0100, Claus Reinke wrote: >>> so i wonder why everyone else claims to be happy with the status quo? >> We aren't happy with the status quo. Rather, we know that no matter how >> much we do, the situation will never improve, so most of us have stopped >> wasting out time. Furthermore, we know that people who DO offer >> alternatives instantly lose all public credibility - look at what >> happened to Alex Jacobson. >> >> Stefan (who will readily admit his bleak outlook) > > Be happy: we're about 15 years ahead of the lisp guys. 'cabal install > xmonad' works, for example. > > -- Don And that, I think, will be the key to the solution. Keeping the repository of interdependent libraries consistent is hard, but it is only a means to an goal. That goal is applications, not libraries. My definition of the right version of libFoo to use is whatever is needed to make an application, such as xmonad, work. -- Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Simon Marlow wrote: > Ultimately when things settle down > it might make sense to do this kind of thing, but right now I think an > easier approach is to just fix packages when dependencies change, and to > identify sets of mutually-compatible packages (we've talked about doing > this on Hackage before). > > Cheers, > Simon When coordinating distribution of separately maintained libraries and projects, the linux distributions do indeed "identify sets of mutually-compatible packages", quite often including small patchfiles to ensure compilation. Thus for linux, cabal is a layer below such apt and rpm repositories and blessing sets of packages would be done at a higher level. Once cabal is being used to automatically retrieve sets of working packages then it is easiest to write cabal to assume that hackage is fixed when dependencies change. As a practical matter, it is easy to see how to identify such sets. Since such sets must be installed by at least one person, that person's ghc-pkg listing is already a precise definition of the working set. All that might need to be done is to publish such a working set on hackage where cabal (or another tool) can see it. Cheers, Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
stefanor: > On Mon, Oct 15, 2007 at 10:57:48PM +0100, Claus Reinke wrote: > > so i wonder why everyone else claims to be happy with the status quo? > > We aren't happy with the status quo. Rather, we know that no matter how > much we do, the situation will never improve, so most of us have stopped > wasting out time. Furthermore, we know that people who DO offer > alternatives instantly lose all public credibility - look at what > happened to Alex Jacobson. > > Stefan (who will readily admit his bleak outlook) Be happy: we're about 15 years ahead of the lisp guys. 'cabal install xmonad' works, for example. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
On Mon, Oct 15, 2007 at 10:57:48PM +0100, Claus Reinke wrote: > so i wonder why everyone else claims to be happy with the status quo? We aren't happy with the status quo. Rather, we know that no matter how much we do, the situation will never improve, so most of us have stopped wasting out time. Furthermore, we know that people who DO offer alternatives instantly lose all public credibility - look at what happened to Alex Jacobson. Stefan (who will readily admit his bleak outlook) signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
On Tuesday 16 October 2007 11:45, Claus Reinke wrote: > >> how about using a provides/expects system instead of betting on > >> version numbers? if a package X expects the functionality of base-1.0, > >> cabal would go looking not for packages that happen to share the name, > >> but for packages that provide the functionality. > > > > Using the version number convention mentioned earlier, "base-1.0" > > funcionality is provided by base-1.0.* only. A package can already > > specify that explicitly. > > not entirely correct. you said that major versions implied api changes. > that does not imply that the api is no longer backwards compatible, > only that there are sufficiently substantial new features that a version > naming them seems called for. while base breaks backwards > compatibility, other packages might not do so. > > and cabal does not allow me to specify anything but a name and a > range of numbers as dependencies (there is exposed-modules:, but > no imported-modules:), so i can't say which parts of base-1.0 my > package depends on, and cabal can't decide which versions of > base might be compatible with those more specific dependencies. I've been giving only cursory attention to this thread so I might have the wrong end of the stick, or indeed the entirely wrong shrub. If the convention for modifying package versions of form x.y.z is: - increment z for bugfixes/changes that don't alter the interface - increment y for changes that consist solely of additions to the interface, parts of the interface may be marked as deprecated - increment x for changes that include removal of deprecated parts of the interface - (optionally) x == 0 => no guarantee and package maintainers are rigorous in following these rules then specifying dependencies as foo-x, foo-x.y, foo-x.y.z should be sufficient. This rigour could largely be enforced by hackage or an automated build system. foo-x is a shortcut for foo-x.0.0 foo-x.y is a shortcut for foo-x.y.0 foo-x.y.z is satisfied by any foo-i.j.k where i=x, j.k>=y.z The 'foo' package name is just an indicator of lineage. foo-2.xxx is not the same package as foo-1.xxx, it's interface is missing something that foo-1.xxx's interface provided. Dependencies of "foo" shouldn't appear in published cabal files. There is a case for their use in development where you are specifying that you want to depend on the very latest version of foo available, perhaps from darcs. When you publish that latest version number gets burned in, eg "foo-2.1.20071016". As for provides/expects and imported-modules instead, isn't that just an arbitrary line drawn in the granularity sand? Perhaps package versions could be expanded to include the type of every function they expose, plus more information to indicate which bugfix version of those functions is present. That's maybe the Right Way... and probably a lot of work. A more convenient place to draw the line seems to be at the package level. > > > I think what you're asking for is more than that: you want us to provide > > base-1.0, base-2.0 and base-3.0 at the same time, so that old packages > > continue to work without needing to be updated. That is possible, but > > much more work for the maintainer. Ultimately when things settle down it > > might make sense to do this kind of thing, but right now I think an > > easier approach is to just fix packages when dependencies change, and to > > identify sets of mutually-compatible packages (we've talked about doing > > this on Hackage before). > > yes. it's called automatic memory management!-) as long as there's > a package X depending on package Y-a.b, package Y-a.b should > not disappear. not having to waste time on such issues is one reason > why programmers are supposed to prefer haskell over non-functional > languages, right?-) I think it's a no-brainer that old versions of packages should remain available for people to use for 'a long time'. If their dependencies are specified properly they should continue building successfully as time passes. Isn't the main problem the use of "foo" dependencies and the resulting version guessing/ambiguity? Presumably it's not usually a problem if indirect package dependencies require incompatible versions of a package. Is this a problem with base because it implicitly has a dependency on a particular version of the GHC internals? Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
However, I'd like to separate it from Cabal. Cabal provides mechanism not policy, regarding version numbers. but the examples in the cabal docs should reflect the standard interpretation of version numbers. of course, i have absolutely no idea how to write stable packages under this interpretation. and the examples in the cabal docs do not explain this, either (neither "bar" nor "foo > 1.2" are any good under this interpretation). base >= 2.0 && < 3.0 that only works if older versions of base are kept side by side with base >= 3.0. otherwise, any package with that range will refuse to build (which may be better than failing to build), even though nothing in that package has changed, and all the features it depends on are still available. Omitted only because it isn't implemented. Well, it is implemented, on my laptop, but I'm not happy with the design yet. i look forward to hearing more. here, you say you are working on an implementation; earlier, you said that re-exporting modules via several packages was not the way forward. cabal is fairly new and still under development, so there is no need to build in assumptions that are sure to cause grief later (and indeed are doing so already). what assumptions does Cabal build in? its documentation is not very precise about what version numbers mean. going by the examples, i thought that 'base' was an acceptable dependency, but it isn't. i also assumed that lower bounds (foo > 1.2) could be relied on, but they can't. perhaps i'm the only one reading the cabal docs this way, but i feel mislead!-) and even if i translate your versioning scheme into cabal dependencies, i end up with explicit version ranges as the only valid option, so the assumption becomes that every package *will* break as its dependencies move on. how about using a provides/expects system instead of betting on version numbers? if a package X expects the functionality of base-1.0, cabal would go looking not for packages that happen to share the name, but for packages that provide the functionality. Using the version number convention mentioned earlier, "base-1.0" funcionality is provided by base-1.0.* only. A package can already specify that explicitly. not entirely correct. you said that major versions implied api changes. that does not imply that the api is no longer backwards compatible, only that there are sufficiently substantial new features that a version naming them seems called for. while base breaks backwards compatibility, other packages might not do so. and cabal does not allow me to specify anything but a name and a range of numbers as dependencies (there is exposed-modules:, but no imported-modules:), so i can't say which parts of base-1.0 my package depends on, and cabal can't decide which versions of base might be compatible with those more specific dependencies. I think what you're asking for is more than that: you want us to provide base-1.0, base-2.0 and base-3.0 at the same time, so that old packages continue to work without needing to be updated. That is possible, but much more work for the maintainer. Ultimately when things settle down it might make sense to do this kind of thing, but right now I think an easier approach is to just fix packages when dependencies change, and to identify sets of mutually-compatible packages (we've talked about doing this on Hackage before). yes. it's called automatic memory management!-) as long as there's a package X depending on package Y-a.b, package Y-a.b should not disappear. not having to waste time on such issues is one reason why programmers are supposed to prefer haskell over non-functional languages, right?-) claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
> but the name that is everywhere does not stand for what the new version > provides! any place that is currently referring to 'base' will have to be > inspected to check whether it will or will not work with the reduced > base package. and any place that is known to work with the new > base package might as well make that clear, by using a different name. base changed its API between 2.0 and 3.0, that's all. The only difference between what happened to the base package between 2.0 and 3.0 and other packages is the size of the changes. In fact, base 3.0 provides about 80% the same API as version 2.0. so it is not just an api extension, nor an api modification with auxiliary definitions to preserve backwards api compatibility, nor a deprecation warning for api features that may disappear in the distant future; it is an api shrinkage - features that used to be available from dependency 'base' no longer are. and it isn't just any package, it is 'base'! the decision to make the difference visible in package names was made when subpackages were created from the old base. if cabal can handle multiple versions of base coexisting, and can guess which version was meant when someone wrote 'base', then no renaming is necessary. but if cabal can't handle that (yet), then renaming might be a workaround, to avoid more trouble. if ghc told me that "expected type 'base' doesn't match inferred type 'base'", i'd file a bug report. why do we throw out such standards when grouping modules into packages? Exactly what percentage change should in your opinion require changing the name of the package rather than just changing its version number? Neither 0% nor 100% are good choices... packaging is rarely clear-cut! then we should ask: why not? it seems to be a standard type system problem: either we have no subtyping, then the types/versions/apis must match precisely, however inconvenient that might be, or we have subtyping, then we need to define what we want it to mean that one package version may be used instead of another. just having names and numbers and schemes that give no guarantees that matches imply compatibility is no solution. i don't want a package manager that tells me: "congratulations! your package is 88.745% likely to be buildable, it provides between 45% and 95% of the features your package spec promises (since all promises are informal, no precise validation is possible, but most users should be happy), provided that our dependencies really do provide all the features we depend on (i have no idea what those features might be). go ahead and publish it. let others clean up the mess. oh, and remember to come back every couple of months or so to clean up the mess made by those providing your package's dependencies.". of course, cabal doesn't even tell me that. it lets me publish anything (shouldn't there be a './Setup check' to validate? or is there?) and only gets involved when people try to build what i published, usually months later, when anything might happen (depending on how good my package spec was, and on what happened to the dependencies in the meantime), followed by someone chasing me, then me chasing someone else, or someone giving up. is this too bleak a view?-) claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
You need a way to specify "foo > 1.2 && foo < 2", which is a suggestion that was tossed around here recently. but what does such a version range say? that i haven't tested any versions outside the range (because they didn't exist when i wrote my package)? or that i have, and know that later versions won't do? Also, you'd need foo 1.x for x>=2 to be available after foo-2.0 arrives. indeed. available, and selectable. so the package manager needs to be able to tell which package versions can be used to fulfill which dependencies. if that decision is based on version numbers alone, we need to be specific about the meaning of version numbers in dependencies. and if the major/minor scheme is to be interpreted as Simon summarised, the only acceptable form of a dependency is an explicit version range (the range of versions known to work). which means that package descriptions have to be revisited (manually) and updated (after inspection) as time goes on. so we seem to be stuck with a choice between breaking packages randomly (because version numbers were too imprecise to prevent breakage accross dependency updates) or having packages unable to compile (because version numbers were needlessly conservative, and newer dependencies that may be acceptable in practice are not listed). neither option sounds promising to me (instead of the package manager managing, it only keeps a record while i have to do the work), so i wonder why everyone else claims to be happy with the status quo? 'base' aside, I don't think we want a system that requires us to rename a library any time incompatible changes are introduced. i was talking only about the base split, as far as renaming is concerned. but i still don't think the interpretations and conventions of general haskell package versioning have been pinned down sufficiently. and i still see lots of issues in current practice, even after assuming some common standards. The major/minor scheme has worked nicely for .so for ages. i'm not so sure about that. it may be better than alternatives, but it includes standards of common practice, interpretation, and workarounds (keep several versions of a package, have several possible locations for packages, renumber packages to bridge gaps or to fake unavailable versions, re-export functionality from specific package versions as generic ones, ...). and i don't think cabal packages offer all the necessary workarounds, even though they face all the same issues. how about using a provides/expects system instead of betting on version numbers? if a package X expects the functionality of base-1.0, cabal would go looking not for packages that happen to share the name, but for packages that provide the functionality. base-not-1.0 would know that it doesn't do that. and if there is no single package that reexports the functionality of base-1.0, cabal could even try to consult multiple packages to make ends meet Scrap cabal in favor of 'ghc --make'? :-) ultimately, perhaps that is something to aim for. i was thinking of a simpler form, though, just liberating the provider side a bit: - currently, every package provides it's own version only; it is the dependent's duty to figure out which providers may or may not be suitable; this introduces a lot of extra work, and means that no package is ever stable - even if nothing in the package changes, you'll have to keep checking and updating the dependencies! - instead, i suggest that every package can stand for a range of versions, listing all those versions it is compatible with; that way, the dependent only needs to specify one version, and it becomes the provider's duty to check and specify which api uses it is compatible with (for instance, if a package goes through several versions because of added features, it will still be useable with its initial, limited api). of course, if you refine that simple idea, you get to typed interfaces as formally checkable specifications of apis (as in the ML's, for instance). and then you'd need something like 'ghc --make' or 'ghc -M' to figure out the precise interface a package depends on, and to provide a static guarantee that some collection of packages will provide those dependencies. Seriously though, how hard would it be to automatically generate a (suggested) build-depends from ghc --make? i'd like to see that, probably from within ghci. currently, you'd have to load your project's main module, then capture the 'loading package ...' lines. there is a patch pending for ghci head which would give us a ':show packages' command. claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Claus Reinke wrote: if this is the "official" interpretation of cabal package version numbers, could it please be made explicit in a prominent position in the cabal docs? Yes - I think it would be a good idea to make that convention explicit somewhere (I'm sure we've talked about it in the past, but I can't remember what happened if anything). However, I'd like to separate it from Cabal. Cabal provides mechanism not policy, regarding version numbers. of course, i have absolutely no idea how to write stable packages under this interpretation. and the examples in the cabal docs do not explain this, either (neither "bar" nor "foo > 1.2" are any good under this interpretation). base >= 2.0 && < 3.0 I believe Cabal is getting (or has got?) some new syntax to make this simpler. why do you omit the most popular (because most obvious to users) option? - if base remains what it is and a new package is created providing the rest of base after the split, then every user is happy (that it is currently hard to implement this by reexporting the split packages as base is no excuse) Omitted only because it isn't implemented. Well, it is implemented, on my laptop, but I'm not happy with the design yet. In the design we've chosen, some packages continue to work without change. Specifying a dependency on a package without giving an explicit version range is a bet: sometimes it wins, sometimes it doesn't. The nice thing is that we have most of our packages in one place, so we can easily test which ones are broken and notify the maintainers and/or fix them. sorry, i don't want to turn package management into a betting system. and i don't see how knowing how much is broken (so cabal can now only work with central hackage?) is any better than avoiding such breakage in the first place. cabal is fairly new and still under development, so there is no need to build in assumptions that are sure to cause grief later (and indeed are doing so already). what assumptions does Cabal build in? Yes I know we've changed other names - very little in packaging is clear-cut. how about using a provides/expects system instead of betting on version numbers? if a package X expects the functionality of base-1.0, cabal would go looking not for packages that happen to share the name, but for packages that provide the functionality. Using the version number convention mentioned earlier, "base-1.0" funcionality is provided by base-1.0.* only. A package can already specify that explicitly. I think what you're asking for is more than that: you want us to provide base-1.0, base-2.0 and base-3.0 at the same time, so that old packages continue to work without needing to be updated. That is possible, but much more work for the maintainer. Ultimately when things settle down it might make sense to do this kind of thing, but right now I think an easier approach is to just fix packages when dependencies change, and to identify sets of mutually-compatible packages (we've talked about doing this on Hackage before). Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Claus Reinke wrote: > Simon Marlow wrote: >> Another reason not to change the name of 'base' is that there would be >> a significant cost to doing so: the name is everywhere, not just in >> the source code of GHC and its tools, but wiki pages, documentation, >> and so on. > > but the name that is everywhere does not stand for what the new version > provides! any place that is currently referring to 'base' will have to be > inspected to check whether it will or will not work with the reduced > base package. and any place that is known to work with the new > base package might as well make that clear, by using a different name. base changed its API between 2.0 and 3.0, that's all. The only difference between what happened to the base package between 2.0 and 3.0 and other packages is the size of the changes. In fact, base 3.0 provides about 80% the same API as version 2.0. Exactly what percentage change should in your opinion require changing the name of the package rather than just changing its version number? Neither 0% nor 100% are good choices... packaging is rarely clear-cut! Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
"Claus Reinke" <[EMAIL PROTECTED]> writes: > if this is the "official" interpretation of cabal package version numbers, > could it please be made explicit in a prominent position in the cabal docs? Me too. This is not a criticism nor endorsement of any particular scheme, just a vote in favor of having a - one, single, universal - scheme. > of course, i have absolutely no idea how to write stable packages under > this interpretation. and the examples in the cabal docs do not explain this, > either (neither "bar" nor "foo > 1.2" are any good under this interpretation). You need a way to specify "foo > 1.2 && foo < 2", which is a suggestion that was tossed around here recently. Also, you'd need foo 1.x for x>=2 to be available after foo-2.0 arrives. 'base' aside, I don't think we want a system that requires us to rename a library any time incompatible changes are introduced. The major/minor scheme has worked nicely for .so for ages. I'd like to make the additional suggestion that a major version number of 0 means no compatibility guarantees. >> Another reason not to change the name of 'base' is that there would >> be a significant cost to doing so: the name is everywhere, not just >> in the source code of GHC and its tools, but wiki pages, >> documentation, and so on. Much like 'fps', now known as 'bytestring', no? I had some problems finding it, true, but the upside is that old stuff is free to reference fps until I can get around to test and update things. > how about using a provides/expects system instead of betting on > version numbers? if a package X expects the functionality of base-1.0, > cabal would go looking not for packages that happen to share the name, > but for packages that provide the functionality. base-not-1.0 would > know that it doesn't do that. and if there is no single package that > reexports the functionality of base-1.0, cabal could even try to consult > multiple packages to make ends meet Scrap cabal in favor of 'ghc --make'? :-) Seriously though, how hard would it be to automatically generate a (suggested) build-depends from ghc --make? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
but calling "split-base" "base" goes directly against all basic assumptions of all packages depending on "base". The new base will have a new version number. There is no expectation of compatibility when the major version is bumped; but we do have an informal convention that minor version bumps only add functionality, and sub-minor version bumps don't change the API at all. if this is the "official" interpretation of cabal package version numbers, could it please be made explicit in a prominent position in the cabal docs? of course, i have absolutely no idea how to write stable packages under this interpretation. and the examples in the cabal docs do not explain this, either (neither "bar" nor "foo > 1.2" are any good under this interpretation). So a package that depends on 'base' (with no upper version bound) *might* be broken in GHC 6.8.1, depending on which modules from base it actually uses. Let's look at the other options: - if we rename base, the package will *definitely* be broken - if the package specified an upper bound on its base dependency, it will *definitely* be broken why do you omit the most popular (because most obvious to users) option? - if base remains what it is and a new package is created providing the rest of base after the split, then every user is happy (that it is currently hard to implement this by reexporting the split packages as base is no excuse) In the design we've chosen, some packages continue to work without change. Specifying a dependency on a package without giving an explicit version range is a bet: sometimes it wins, sometimes it doesn't. The nice thing is that we have most of our packages in one place, so we can easily test which ones are broken and notify the maintainers and/or fix them. sorry, i don't want to turn package management into a betting system. and i don't see how knowing how much is broken (so cabal can now only work with central hackage?) is any better than avoiding such breakage in the first place. cabal is fairly new and still under development, so there is no need to build in assumptions that are sure to cause grief later (and indeed are doing so already). Another reason not to change the name of 'base' is that there would be a significant cost to doing so: the name is everywhere, not just in the source code of GHC and its tools, but wiki pages, documentation, and so on. but the name that is everywhere does not stand for what the new version provides! any place that is currently referring to 'base' will have to be inspected to check whether it will or will not work with the reduced base package. and any place that is known to work with the new base package might as well make that clear, by using a different name. Yes I know we've changed other names - very little in packaging is clear-cut. how about using a provides/expects system instead of betting on version numbers? if a package X expects the functionality of base-1.0, cabal would go looking not for packages that happen to share the name, but for packages that provide the functionality. base-not-1.0 would know that it doesn't do that. and if there is no single package that reexports the functionality of base-1.0, cabal could even try to consult multiple packages to make ends meet (provided that someone told it that 'expects: base' can be met by 'provides: rest-base containers ..'). claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Claus Reinke wrote: but calling "split-base" "base" goes directly against all basic assumptions of all packages depending on "base". The new base will have a new version number. There is no expectation of compatibility when the major version is bumped; but we do have an informal convention that minor version bumps only add functionality, and sub-minor version bumps don't change the API at all. So a package that depends on 'base' (with no upper version bound) *might* be broken in GHC 6.8.1, depending on which modules from base it actually uses. Let's look at the other options: - if we rename base, the package will *definitely* be broken - if the package specified an upper bound on its base dependency, it will *definitely* be broken In the design we've chosen, some packages continue to work without change. Specifying a dependency on a package without giving an explicit version range is a bet: sometimes it wins, sometimes it doesn't. The nice thing is that we have most of our packages in one place, so we can easily test which ones are broken and notify the maintainers and/or fix them. Another reason not to change the name of 'base' is that there would be a significant cost to doing so: the name is everywhere, not just in the source code of GHC and its tools, but wiki pages, documentation, and so on. Yes I know we've changed other names - very little in packaging is clear-cut. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
