On Fri, 2008-05-02 at 00:28 +0200, Thomas Schilling wrote:
On 20 apr 2008, at 22.22, Duncan Coutts wrote:
[Replying so late as I only saw this today.]
I believe that using tight version constraints in conjunction with the PVP to be a good solution. For now.
I think I tend to agree.
I don't quite know how Searchpath works (the website is rather taciturn), but I think that we should strive for a better approximation to real dependencies, specifically, name, interface, and semantics of imported functions. As I see it, what's missing is proper tool support to do it practically for both library authors and users.
Yes, we can make package name and version a better approximation of the package interface with tools to enforce the versioning policy.
Library users really shouldn't need to do anything except to run a tool to determine all dependencies of a given package. Library authors should be able to run a tool that determines what's new and what might have changed. The package author then merely decides whether semantics was changed and if so, in what way (i.e., compatible or not to previous semantics). Packages will still carry versions, but they are only used to mark changes. Semantic information is provided via a "change database" which contains enough information to determine whether a version of a package contains appropriate implementations of the functions (or, more generally, entities) used in a dependent package.
For example, if we write a program that uses the function 'Foo.foo' contained in package 'foo' and we happen to have used 'foo-0.42' for testing of our program. Then, given the knowledge that 'Foo.foo' was introduced in 'foo-0.23' and changed semantics in 'foo-2.0' then we know that 'foo >= 0.23 && < 2.0' is the correct and complete dependency description.
That's the ideal, maybe we can work towards this? Or does this sound crazy?
I think extracting package APIs and comparing them across versions is an excellent thing to do. It'd help users see what has changed and it'd let us enforce the versioning policy (at least for interface changes, not for semantic changes). Having a central collection of those interfaces and using that to work out which versions of which packages would be compatible with the program I just wrote is quite an interesting idea. It's related to what I was saying about identifying code by it's full interface, as a functor, but then using that to map back to packages that provide the interface. Something like that might go some way to addressing David Roundy's quite legitimate criticism that the system of specifying deps on package names and versions requires one to know the full development history of that code, eg to track it across package renames. However it would only help for the development _history_, we still have no solution for the problem of packages being renamed (or modules moving between packages) breaking other existing packages. Though similarly we have no solution to the problem of modules being renamed. Perhaps it's just that we have not done much module renaming recently so people don't see it as an issue. Duncan