Re: [Haskell] Re: Trying to install binary-0.4
Duncan and I have started a wiki page to collect proposals for ways to avoid or alleviate the pain from future package reorganisations. http://hackage.haskell.org/trac/ghc/wiki/PackageCompatibility It's been helpful for me to write all this down, the issues seem much clearer. However, I don't see an obviously best solution. For me proposal 4.2 (see the wiki page) looks the most promising, but it doesn't provide complete backwards compatibility, so I imagine there will be people who disagree. Please read the page. Fix problems, add rationale, add proposals if you have any that are substantially different from those already there. For general discussion just reply to this message (replies directed to [EMAIL PROTECTED]). Cheers, Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[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. As you notice the configurations syntax for this purpose is a bit clumsy, because
Re: [Haskell] Re: Trying to install binary-0.4
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. 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?). 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? For the time being, I'll go with 'ghc --make'. And I think that cabal configurations are an exceptionally bad idea carried to perfection. 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.) 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? 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... -Udo signature.asc Description: Digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[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. When hackage itself is using Cabal-1.2.1 then I can
Re: [Haskell] Re: Trying to install binary-0.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Udo Stenzel wrote: [an entertaining report on cabal/ghc problems] = module Data.ByteString.Base not found I also got stuck there when trying to build zlib-0.3 (prerequisite for cabal-install-0.3.0) (with ghc-6.8.0.20070918) I don't even know whether cabal-install is what I want. It downloads a source package from hackage, builds and installs? Best regards, Johannes Waldmann. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHGGiV3ZnXZuOVyMIRAoopAJ92RIOHVMX3LlTO2vGu5UTPCOAXkwCglcaf 3gSUPSneA27Mk0ytNiP9K/4= =H3zX -END PGP SIGNATURE- ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
On Fri, 2007-10-19 at 01:00 +0200, Udo Stenzel wrote: Don Stewart wrote: If I understand correctly, the main issue for Udo is simply that the MonadFix instance is required by his code, and isn't available in binary 0.3 -- the version to be used on earlier GHCs. Is that right Udo? No, the issue is that nothing works. I replied earlier to Udo but just for the benefit of everyone else... The current darcs versions of binary and tar work with ghc-6.4, 6.6 and 6.8.x. They do require Cabal-1.2.x, but that also works with ghc 6.4 to 6.8. The bytestring package also works with 6.4 and 6.8. The Data.ByteString code was included in base in ghc-6.6 so the bytestring package is not needed for ghc-6.6. 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. The fps package is archaic and should be ignored. There is quite a bit of churn with ghc-6.8 because of the base package having been split up. This requires changes to the .cabal files of many packages to allow them to continue to build with old and new versions of ghc. 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. Duncan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
Don Stewart wrote: If I understand correctly, the main issue for Udo is simply that the MonadFix instance is required by his code, and isn't available in binary 0.3 -- the version to be used on earlier GHCs. Is that right Udo? No, the issue is that nothing works. It turns out that I actually wanted the MonadFix instance for something unrelated, only at about the same time (and using runGetState, I can even work around that if I want). Here's the story of how not to intall tar-1.0 on GHC 6.4: - I'm on a Ubuntu system, GHC 6.4 has been installen from .deb packages, my local GHC config is empty. - I unpack tar-1.0 and try to run Setup configure on it = module Distribution.Simple does not export UserHooks(confHook) - I need a more recent cabal, my choice is cabal-1.1.6.2, which install flawlessly. - back to tar-1.0 = base = 2.0 is required, = unix-1.0 is used for unix-any This is already messed up, tar wants unix-compat, not unix-any. (Or is it? See below.) Apparently, it is a fatal error to have a dash in any package name. This explains why System.PosixCompat will never be found, no matter how often I install it. - Since binary is also needed, I'll now install binary-0.3 = could not find module Data.ByteString - So I need ByteString. It is not in Hackage. Googling around leads me to http://www.cse.unsw.edu.au/~dons/fps.html, where I download fps-0.7, since fps is what binary.cabal mentions in a comment. - fps-0.7 install flawlessly. - back to building binary = constructor LPS is not found - no newer fps is available, I get bytestring from darcs - bytestring wants a newer cabal. But my patience is already running out, so instead I edit the cabal file, and it installs. - back to building binary = module Data.ByteString.Base not found At this point I'm fed up, delete the whole setup and go back to the one I already hacked up to work with binary-0.4. Getting binary-0.4 and hammering it into shape to run on GHC 6.4 would have been the next step anyway, and after that, tar-1.0 needs to be edited to refer to System.Posix and then it would probably work. I dimply remember that it was also impossible to install unix-compat because the wrong cabal was picked up and I ended up throwing out unix-compat completely. Okay, summarizing, what did cabal do for me? Well, it helped me install a new version of cabal and an obsolete version of something else. Sorry, but this whole experience is a huge turnoff. With things going that smoothly, I'm better off using ghc --make and distributing the stuff I cannot rely on directly with my code. Now here's the story for GHC 6.6: - I'm on Debian testing, GHC 6.6.1 is installed, cabal is 1.1.6.2. I'm in a fresh user account without local additions to GHC. - download tar-1.0, unpack and configure. Binary is needed. - download binary-0.3, installs flawlessly. - back to tar-1.0. Now this is weird: = Dependency unix-any: using unix-2.1 = cannot satisfy dependency unix-compat=0.1 Why does it want *both* unix and unix-compat? The .cabal file mentions only one of them, unix-compat. - download unix-compat, installs flawlessly. - tar works now So things look a lot better on GHC 6.6, but only because I used binary-0.3 instead of 0.4, and I did this only because Don recently mentioned it. Suppose I tried binary-0.4 (because I want 'instance MonadFix Get' or because I don't know better): - dependencies on split base cannot be fulfilled. I have to edit the cabal file. - bytestring needs to be updated - a new cabal is needed - the description of base has to be patched to remove the conflict with base - binary-0.4 installs now - try to configure tar-1.0 = Could not find module `Distribution.Setup' This is no fun at all. Not only do I have to work around the incompatible changes in base, the interface of Cabal also changed in an incompatible way. -Udo -- My teachers could easily have ridden with Jesse James for all the time they stole from me. -- Richard Brautigan signature.asc Description: Digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
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 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
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
[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
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
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
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
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
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
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
[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
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
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
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
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
- 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
[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
[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
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
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
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
[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
[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
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: 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
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
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
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
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
[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
[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
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
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
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
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
[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
Re: [Haskell] Re: Trying to install binary-0.4
igloo: On Sun, Oct 14, 2007 at 05:19:31PM +0200, Udo Stenzel wrote: Ian Lynagh wrote: People interested in making it easy to use new versions of packages with old compiler releases can make a small script that installs empty Cabal packages called bytestring, containers, array, etc. That completely misses the fact that bytestring cannot be upgraded, no matter how many fake packages are available. Ah, you mean the problem is that it really does depend on some change in bytestring (the internal API?), rather than just having a dependency on the bytestring package? Then yes, things are not so easy. Part of the motivation for splitting up base is so that this sort of thing is easier in the future. Yes, this was exactly the motivation for not back porting the binary library to 6.4 and earlier: it depends on representation details of ByteString that I'm not going to cpp into portability. If I understand correctly, the main issue for Udo is simply that the MonadFix instance is required by his code, and isn't available in binary 0.3 -- the version to be used on earlier GHCs. Is that right Udo? If that's the case, manually inserting that instance when using binary 0.3 seems easy enough. -- Don ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
On Fri, 2007-10-12 at 01:27 +0200, Udo Stenzel wrote: Don Stewart wrote: Since you're not using ghc 6.8, you should use binary 0.3 :) That was PC for sorry, GHC 6.6 is no longer supported and don't even ask about 6.4 As far as I can see, there's no good reason why binary, tar, etc cannot work with ghc-6.4, 6.6 and 6.8. I've made it work for my zlib iconv libs just fine without too much cpp'ery. So I'm going to try and fix binary, tar etc to work with all recent ghc. Stay tuned. Obviously it'll need the newest Cabal, but that works with all versions of ghc back to 6.2, and it can be installed as user. Duncan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[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
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
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
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 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
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
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
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
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
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
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] Re: Trying to install binary-0.4
Bjorn Bringert wrote: The tar package uses System.PosixCompat from the unix-compat package to also work under non-posix systems (read Windows). This dependency is listed in the tar.cabal file (see http://hackage.haskell.org/ packages/archive/tar/0.1/tar.cabal). System.Posix was never renamed. [...] Why not just install unix-compat? It is listed as a dependency after all. Actually Windows claims to be a Posix system, too (not that I really believe it or care much). Iirc, unix-compat blew up on GHC 6.4, too, again by picking up the wrong Cabal. I'll check this again tomorrow (don't have access to that machine right now). Anyway, I don't see why something that provides the same functionality as something else needs a different name. With the mechanism of something like apt (Provides, Conflicts, Replaces, ...) I'd have no problem, but Cabal doesn't do that stuff. Maybe it should, though. I seem to be able to build the tar package against binary-0.3. What exactly is the error that you are getting? No instance MonadFix Get (from memory, I can check this again once I calm down...) By the way, I don't think that users of open source software have a right to be pissed off, or at least authors don't have an obligation to care about them being pissed off. What users do have is a right to submit patches. No sir, I always have a right to be pissed off. What I don't have is a right to demand anything from you. The problem with patches is how do you patch something as thoroughly messed up as 'base-2.0' vs. 'base-2.1' vs. 'base-2.1.1'? If I saw a way to fix it, you'd already have a patch, but all I have right now is a GHC with an afroengineered package configuration and a mutilated tar package... That said, I agree that the constantly changing packages make it hard to keep dependencies up to date. Moreover, the conical place to find packages is Hackage, right? Tar is there, unix-compat is and binary is, too. But bytestring is missing. Which means you have to hunt down bytestring separately, and cabal-get will fail, too. It also means that some of these packages cannot work on any released version of GHC. I guess that this is price we pay for moving quickly. Is it impossible to move quickly on GHC 6.4? -Udo signature.asc Description: Digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
Hi Udo, On Fri, Oct 12, 2007 at 01:27:11AM +0200, Udo Stenzel wrote: - Provide a replacement configuration for GHC 6.6 and 6.4 (yes, that one is still alive!) that removes the conflict between 'base' and 'bytestring' and pretends to provide bytestring, containers, array, etc. People interested in making it easy to use new versions of packages with old compiler releases can make a small script that installs empty Cabal packages called bytestring, containers, array, etc. Then link to it from appropriate places on the wikis, and everyone can benefit from it. Thanks Ian ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
Ian Lynagh wrote: People interested in making it easy to use new versions of packages with old compiler releases can make a small script that installs empty Cabal packages called bytestring, containers, array, etc. That completely misses the fact that bytestring cannot be upgraded, no matter how many fake packages are available. -Udo signature.asc Description: Digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
On Sun, Oct 14, 2007 at 05:19:31PM +0200, Udo Stenzel wrote: Ian Lynagh wrote: People interested in making it easy to use new versions of packages with old compiler releases can make a small script that installs empty Cabal packages called bytestring, containers, array, etc. That completely misses the fact that bytestring cannot be upgraded, no matter how many fake packages are available. Ah, you mean the problem is that it really does depend on some change in bytestring (the internal API?), rather than just having a dependency on the bytestring package? Then yes, things are not so easy. Part of the motivation for splitting up base is so that this sort of thing is easier in the future. Thanks Ian ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
On Oct 14, 2007, at 12:48 , Ian Lynagh wrote: On Sun, Oct 14, 2007 at 05:19:31PM +0200, Udo Stenzel wrote: Ian Lynagh wrote: People interested in making it easy to use new versions of packages with old compiler releases can make a small script that installs empty Cabal packages called bytestring, containers, array, etc. That completely misses the fact that bytestring cannot be upgraded, no matter how many fake packages are available. Ah, you mean the problem is that it really does depend on some change in bytestring (the internal API?), rather than just having a dependency on the bytestring package? I think dons has said that the latest bytestring depends on some GHC 6.8 internals that can't reasonably be backported, so if you need the new bytestring API, you're kinda stuck. -- 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 mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
- Provide a replacement configuration for GHC 6.6 and 6.4 (yes, that one is still alive!) that removes the conflict between 'base' and 'bytestring' and pretends to provide bytestring, containers, array, etc. People interested in making it easy to use new versions of packages with old compiler releases can make a small script that installs empty Cabal packages called bytestring, containers, array, etc. there are implicit assumptions in most package managers: - unless you ask for a specific package version, any version will do - if you need a minimum feature set, giving a *lower* bound for the package version will do unless you want to keep updating your package spec every time a new version of a dependency comes out, you really do not want to give *upper* bounds on package versions. haskell software frequently violates both assumptions, deprecating features for one or two a minor versions, then abandoning them in the next. but calling split-base base goes directly against all basic assumptions of all packages depending on base. i don't know whether the first intel ai should really still be expected to run the original excel code without change, but suggesting that people keep going back to make old software compatible with continuosly changing new assumptions does not sound right at all. claus ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
Simon Marlow wrote: - Provide a known good cabal. Make sure it installs on GHC 6.6 and 6.4. Cabal 1.2 works all the way back to GHC 6.2. The recommended way to build new packages with an old GHC will be to upgrade Cabal first. Can it be installed by a user? Because I think my GHC 6.4 always picks up Cabal-1.0, which is installed globally. tar-1.0 then fails through not finding Distribution.Simple. - Refrain from renaming stuff. System.Posix is a fine name. Who renamed it? It's still called System.Posix AFAIK. tar references System.PosixCompat, which apparently comes from a library called unix-compat. I have no idea why the lib isn't just called unix and the modules not System.Posix.*, for tar works fine with System.Posix.*. Personally I object to ECT, it's too heavy. I believe versioning belongs in the package system where it currently is. Well, versioning of shared libraries belongs into the dynamic linker, where it currently is. My gut says, Cabal is more like ld than apt-get. Of course I don't care for the solution ultimately implemented, as long as it works. However, without guidelines for what can be changed between versions of packages, nothing will. The main problem you seem to be running into is that base previously contained bytestring, but you need to upgrade bytestring in order to use binary, right? Actually I'm more annoyed by the many small and unneccessary stumbling blocks right now. I mean, you could easily put an instruction into the INSTALL file that says if you're on GHC 6.4 or 6.6, register this replacement configuration for base to sanitize it. You cannot write if you're on 6.4, edit all references to System.PosixCompat, unless you already installed unix-compat, and you absolutely need binary 0.4, unless you're on 6.4, where you want binary 0.3 but need to patch it so it has instance MonadFix Get, etc. pp. there, since something like that just pisses off your users. But yes, base and bytestring not liking each other is the showstopper, since base can neither be hidden nor upgraded. In that case, I think a reasonable hack is to modify the package configuration for base to move Data.ByteString from exposed-modules to hidden-modules (I'd be wary about removing it altogether). Perhaps the bytestring Setup.lhs should do this automatically when registering? First off, this should be documented. Having bytestring's Setup do the messy registering would be a good solution, I think. A better one than a gazillion Cabal configurations, I might add. -Udo signature.asc Description: Digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
On Oct 13, 2007, at 20:35 , Udo Stenzel wrote: Simon Marlow wrote: - Refrain from renaming stuff. System.Posix is a fine name. Who renamed it? It's still called System.Posix AFAIK. tar references System.PosixCompat, which apparently comes from a library called unix-compat. I have no idea why the lib isn't just called unix and the modules not System.Posix.*, for tar works fine with System.Posix.*. The tar package uses System.PosixCompat from the unix-compat package to also work under non-posix systems (read Windows). This dependency is listed in the tar.cabal file (see http://hackage.haskell.org/ packages/archive/tar/0.1/tar.cabal). System.Posix was never renamed. The main problem you seem to be running into is that base previously contained bytestring, but you need to upgrade bytestring in order to use binary, right? Actually I'm more annoyed by the many small and unneccessary stumbling blocks right now. I mean, you could easily put an instruction into the INSTALL file that says if you're on GHC 6.4 or 6.6, register this replacement configuration for base to sanitize it. You cannot write if you're on 6.4, edit all references to System.PosixCompat, unless you already installed unix-compat, and you absolutely need binary 0.4, unless you're on 6.4, where you want binary 0.3 but need to patch it so it has instance MonadFix Get, etc. pp. there, since something like that just pisses off your users. Why not just install unix-compat? It is listed as a dependency after all. I seem to be able to build the tar package against binary-0.3. What exactly is the error that you are getting? By the way, I don't think that users of open source software have a right to be pissed off, or at least authors don't have an obligation to care about them being pissed off. What users do have is a right to submit patches. That said, I agree that the constantly changing packages make it hard to keep dependencies up to date. I guess that this is price we pay for moving quickly. At some point, however, we will have to stop breaking things. /Björn ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
Udo Stenzel [EMAIL PROTECTED] writes: [incompatibilities between recent libraries/cabal/ghc] I'm installing a GHC-6.8 snapshot, and compiling a bunch of libraries I need in the process (HTTP, HXT, and binary). No show-stoppers, but a lot of rewriting of the dependencies. At least ghc will tell me which package to add, and after a bunch of iterations of this, things work nicely. +1 to renaming the new base, and have 'base' be a compatibility package incorporating 'containers', 'array', etc, with compatible interfaces. (Versioning isn't as good, I think, because it's too common to specify just 'base' without any version. At least, I know I do.) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
Ketil Malde wrote: +1 to renaming the new base, and have 'base' be a compatibility package incorporating 'containers', 'array', etc, with compatible interfaces. (Versioning isn't as good, I think, because it's too common to specify just 'base' without any version. At least, I know I do.) There's currently no (easy) way to make a package that just re-exports the contents of other packages. I've been thinking about ways to do this recently, but I'm now convinced that adding direct support to Cabal and the rest of the packaging infrastructure to do this is the wrong way. I'll try to write down my thoughts and post it sometime. Cheers, Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
Udo Stenzel wrote: - Provide a known good cabal. Make sure it installs on GHC 6.6 and 6.4. Cabal 1.2 works all the way back to GHC 6.2. The recommended way to build new packages with an old GHC will be to upgrade Cabal first. - Start fixing dependencies. In progress for the GHC 6.8.1 release, I believe (dcoutts is on the case). - Refrain from renaming stuff. System.Posix is a fine name. Who renamed it? It's still called System.Posix AFAIK. - Refrain from always using the latest interface of everything. While we're at it, the ability to have multiple versions of a library installed under the same name is a recipe for desaster, too. It should be dropped, instead implementing Eternal Compatibility in Theory by encoding version numbers in module names. Personally I object to ECT, it's too heavy. I believe versioning belongs in the package system where it currently is. Sorry for the rant, but the situation was actually better before Cabal tried to fix everything and in the process broke both versions of GHC that are in widespread use right now. The main problem you seem to be running into is that base previously contained bytestring, but you need to upgrade bytestring in order to use binary, right? In that case, I think a reasonable hack is to modify the package configuration for base to move Data.ByteString from exposed-modules to hidden-modules (I'd be wary about removing it altogether). Perhaps the bytestring Setup.lhs should do this automatically when registering? Cheers, Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
Simon Marlow [EMAIL PROTECTED] writes: +1 to renaming the new base, and have 'base' be a compatibility package incorporating 'containers', 'array', etc There's currently no (easy) way to make a package that just re-exports the contents of other packages. Presumably the hard way would be to simply compile a 'base' consisting of all the modules from those packages? Would that be an option? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
Udo Stenzel wrote: - install exactly one version of cabal, 1.1.6.2, and *remove* all others, - ask ghc-pkg for the description of base, then edit Data.ByteString out of that and re-register it, I forgot, I also tried tar-1.0 on GHC 6.6, and had the same problem there. Even after updating Cabal, there was no way to install 'bytestring' due to the conflict with 'base'. A modified package description for 'base' helped. The reason that tar absolutely wants new stuff is 'instance MonadFix Get', which is not in binary-0.3. If you absolutely want users of GHC 6.6 to stick with binary-0.3, then you should provide a maintenance release binary-0.3.1. And we're back to Eternal Compatibility in Theory... -Udo signature.asc Description: Digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Trying to install binary-0.4
Don Stewart wrote: Since you're not using ghc 6.8, you should use binary 0.3 :) That was PC for sorry, GHC 6.6 is no longer supported and don't even ask about 6.4 The other day I tried to install the tar library on a GHC 6.4. It's nearly impossible. The old base library gets in the way of installing bytestring, binary 0.4 absolutely needs bytestring 0.9 and tar absolutely needs binary 0.4, but still won't compile because System.Posix is now called System.PosixCompat which actually makes it incompatible. Oh, and everything needs a new cabal, but the setup scripts still picks up the wrong one (apparently, since Distribution.Simple is supposed to be there but GHC doesn't find it). Wanna know the solution? - install exactly one version of cabal, 1.1.6.2, and *remove* all others, - ask ghc-pkg for the description of base, then edit Data.ByteString out of that and re-register it, - install bytestring 0.9, - install binary 0.4, - edit the Setup.lhs of tar (it still won't run, even though it should), - edit the source of tar, changing System.PosixCompat to System.Posix, - install it. Should I mention that this is made even more difficult by not being root on the machine in question? All this happened with libraries that look as if they are supposed to be stable, but absolutely nothing works right out of the box. Oh, and Cabal Configurations will make it worse, not better. Here's what should be done, imho: - Rename 'base' ASAP and especially before GHC 6.8 comes out, call it 'foundation' or something else. If you want to keep the name 'base', make sure Cabal considers 'base-2.x' a different library than 'base-3.x'. - Provide a replacement configuration for GHC 6.6 and 6.4 (yes, that one is still alive!) that removes the conflict between 'base' and 'bytestring' and pretends to provide bytestring, containers, array, etc. - Provide a known good cabal. Make sure it installs on GHC 6.6 and 6.4. - Start fixing dependencies. - Refrain from renaming stuff. System.Posix is a fine name. - Refrain from always using the latest interface of everything. While we're at it, the ability to have multiple versions of a library installed under the same name is a recipe for desaster, too. It should be dropped, instead implementing Eternal Compatibility in Theory by encoding version numbers in module names. Sorry for the rant, but the situation was actually better before Cabal tried to fix everything and in the process broke both versions of GHC that are in widespread use right now. -Udo signature.asc Description: Digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
On Fri, Oct 12, 2007 at 01:27:11AM +0200, Udo Stenzel wrote: - Rename 'base' ASAP and especially before GHC 6.8 comes out, call it 'foundation' or something else. If you want to keep the name 'base', make sure Cabal considers 'base-2.x' a different library than 'base-3.x'. - Provide a replacement configuration for GHC 6.6 and 6.4 (yes, that one is still alive!) that removes the conflict between 'base' and 'bytestring' and pretends to provide bytestring, containers, array, etc. +10 Stefan signature.asc Description: Digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
