exposed packages and cabal depends

[Simon Marlow]

Hi Alex,

On 08 April 2005 16:09, S. Alexander Jacobson wrote:

> This choice adds complexity without adding value.

It adds a lot of value: it will prevent untracked dependencies from
creeping into Cabal packages.  That's gotta be a good thing, right?

With -hide-all-packages, there are no exposed packages by defualt, which
is what you were arguing for!

> The simplest approach would be for -i to take precedence over
> default packages.

That only partly solves the problem - you can still write source code
that depends on environmental settings by importing modules from exposed
packages.

Even so, it seems a reasonable suggestion.  We thought about it, but
discovered that it leads to more problems: you can allow a local module
M to override a module M in a package P only as long as nothing from P
is required by any module in the current program.  To know that, you
have to examine all the modules in the current program, which is
difficult when doing separate compilation.  You could end up with some
modules compiled in a context that thinks M is a local module, and
others compiled thinking M comes from package P.  Bad things probably
happen, and it's not clear that we can always tell that this has
happened before delivering the executable.  At the least, the error
turns up at unpredictable points (eg. when you turn optimisation on).

> The -hide-all-packages approach creates much higher risk of testing
> in a package context out of sync with the world at large.

Hmm, I don't think you've understood what -hide-all-packages does.  It
gives you a *consistent* view of packages across all installations: it
eliminates differences between what packages are exposed by default at
different sites.  That is a Good Thing.

You'd probably be more comfortable if -hide-all-packages was the
default.  Well, I'm not going to argue with that, except to say that it
probably will be the default when using Cabal.

> What we really need is a community consensus system (wiki or dns)
> for mapping module names to package locations and for
> implementations to interpret modules in this context.

Hackage will effectively provide a function from 

  Module -> [Package]

that's what you want, right?  But we don't want a single centralised
registry for module names, so it will also be possible to get packages
from source other than Hackage.

> Package names that are not URLs add complexity without value.

Just think of all our existing packages as having an implicit prefix of
http://haskell.org/packages/ (or something).  Does that help?  We'll get
full URLs as package names in the future (at least, that's what I'd like
to see).

Cheers,
	Simon