Stop untracked dependencies!

[Simon Marlow]

On 01 April 2005 07:31, S. Alexander Jacobson wrote:

> 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.

I'll comment on the overall goal then: I'm in complete agreement that
requiring dependencies to be specified is a good thing.

For some reason you want to do this with language extensions or compiler
extensions rather than using Cabal - but this is one of the things that
we expected Cabal to address, which is why you're getting some pushback.
I'm interested in why you're avoiding Cabal: if you could elaborate on
that (perhaps in a separate thread) we might be able to make some
improvements.

You've identified a few problems with the current system:

(a) some packages are exposed by default, which leads to people being
    able to write code without knowing (or needing to know) which
    packages they're using, resulting in untracked dependencies.

I think this is a compromise, and I think it's a good one.  Being able
to just import any of the hierarchical modules I have installed on my
system without having to give a -package flag is really useful (don't
touch that keyboard! I haven't finished yet :-).

If I decide that I want to give the code to someone else, then the
dependencies become important.  This is where Cabal comes in: if you're
not already using Cabal as a plain build system, then you probably want
to use it  to ship the code to someone else anyway.  And at that point
you're forced to enumerate the dependencies.

Sure, we currently have a problem that the dependencies in Cabal are
unchecked, but that's just a bug.  (I'm coming around to Isaac's earlier
suggestion of -fhide-all-packages, actually).

(b) dependencies aren't specified per-module.  I can't express that
    I expect module M to come from package P.

I see this as documentation, but I agree it's useful documentation, and
it would be even more useful if it were automatically checked.  I don't
see any fundamental problem with adding this to Cabal.

>>> * Oh, we made local changes too!? What were they?
> 
> Does Cabal/Hackage notify the user of differences between official
> packages and local versions?  If not, this is another untracked
> dependency.

If you modify a package, you're required to give it a new version number
and/or a different package name.  No this isn't checked, but it could be
(calculating a hash of the external interface of the package, for
example).

>>> * But what happens if I don't have root/admin on the target
>>> machine? [...] 
>>> * Oh, this package conflicts with something already installed?
>>> [etc.] 
> 
> Are some packages allowed to modify the haskell implementation itself?
> More risk of untracked dependencies.

Nope, they aren't (fortunately).  This is one reason we removed the
extra_ghc_options field that used to be in the package config.

Cheers,
	Simon