Alex writes:
I want to allow the user to know exactly which implementations they are using when they import a module-id while at the same time giving them maximal choice of implementations to use. Everything else here is just details.
Great! I believe this is exactly one of the problems that Cabal + Hackage set out to solve. We more-or-less agree on the problem, so now the details of a solution do need to be debated, and hopefully we will end up with a better design, with better coverage of the main use cases. Your email had plenty of useful observations and questions, and I don't have answers to all of them. So here are my thoughts on just a few of your points.
* Uh Oh. Google reveals at least three different implementations... * Now, how do I determine which one is installed here?
Silence on which implementation are actually used creates a second untracked dependency.
I recall that Cabal had (at some early design stage) the ability to specify a range of version numbers on each package dependency, e.g. Foo requires Bar, any version between 1.2 and 1.8. The ranges are open, so you could say "anything > 6.2" for instance.
The implicit point here is that Cabal does not guarantee a mapping from a module identifier to a particular implementation.
If you specify a singular package version, then you get a particular individual implementation, but it could be useful to be more flexible as well, where any one of several implementations would suffice.
And even if you specify a build-depends, Cabal still does not provide any guarantees about the integrity of package namespace.
The community oversees the namespace (currently). It is a social process, which means there will be occasional mistakes, misunderstandings, and changes. If you really want /guarantees/ of non-overlaps, then an automated central authority is inevitable. That would be OK, but then you said the following...
Requiring that packages be listed in some centralized database may help, but it seems like the worst form of bureacracy.
On your specific questions:
How does code get into the database?
The author submits it. (Think wiki.)
Who controls package namespace?
If there is a centralised authority, then it can be automated in a way similar to the DNS. The author of a package suggests a name, and the authority accepts it, provided only that it does not already exist.
What if I don't want to share all my code with the operators of the hackage server?
Then you get into the idea of additional, local, private, servers, over which you hold authority. With this distributed authority however, you now need to come up with a policy on overlaps between the central public namespace, and the local private one. I would guess probably "private overrides public" is a reasonable policy.
Who is allowed to modify packages on the hackage server?
The author. If the author decides not to continue with a package, then they could delegate to a maintainer. I would expect some packages to become orphaned, with no maintainer. On the one hand, that means the package is pretty stable for users. :-) But on the other, it means no-one has authority to fix bugs either. So I would expect that orphaned packages could be "held in trust for the community" or something - i.e. an administrator could give temporary permission to someone to update it when necessary.
And, if there is more than one hackage database/server, then we don't have a centralized database anymore.
The DNS system has thousands of servers, and something like seven "root" servers, yet it seems to manage pretty well...
[...]
Regards, Malcolm