Stop untracked dependencies!

[Malcolm Wallace]

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