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
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
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
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
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
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
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
