Stop untracked dependencies!
Malcolm.Wallace at cs.york.ac.uk
Fri Apr 1 03:26:59 EST 2005
> 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
> >> * 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
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
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...
More information about the Libraries