[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4

[Daniel McAllansmith]

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