Stop untracked dependencies!

[Benjamin Franksen]

On Friday 01 April 2005 21:31, S. Alexander Jacobson wrote:
> * We Need Free Packaging
>
> Anyone should be able to create a package at any time for use in their
> projects without having having to negotiate with any particular
> centralized authority or community.

I competely agree with this.

> HTTP URLs have this property.  The current package namespace does not.
> Malcolm says "think wiki."  I say: think world wide web.

I may be wrong, but AFAIK, the "current package namespace" is whatever you 
have installed on your system (plus what you installed as 'user'). There is 
no central control as long as you don't distribute your code to the internet. 
You can give your internal packages the same name as some (via hackage) 
'officially registered' package. A conflict will arise only when you try to 
install a different package with the same name as yours.

> * Free Packaging Means We To Handle Collisions in Module Namespace
>
> Anyone should be able to use any combination of packages they want in
> any of their programs at any time without worrying about whether those
> packages export the same module name.
>
> Simon says:
> > We don't allow programs to contain two modules with the same name, for
> > good reasons.
>
> I'm not asking for that.  I am totally ok with each module name
> mapping to one and only one implementation per program.  I just want
> to be able choose that implementation even when my program uses two
> packages that both happen to export the same module name.

I agree that this would be /very/ nice to have. But this can be solved in 
Cabal with a configuration file that gives the package name for (only) those 
modules that (1) are imported and (2) appear in more than one used package. 
For each such module, the file states from which package the module should be 
taken. Cabal should complain as long as there are unresolved module name 
conflicts.

> * We Need to Associate Module Names with Specific Packages
>
> In associating module names with particular packages, the design
> choices come down to:
>
>    a. using a "Modules" file that maps module names to package ids/URLs
>
>    b. allowing package ids/URLs in import statements
>
>    c. allowing package *names* in import statement and using an
>       external "Packages" file to map package
>       names to package ids/URLs.
>
> You could extend Cabal to implement (a).  I just think (a) is really
> annoying because it forces you to edit an external packages file every
> time you do an import.

See above: this is only necessary in case of an actual conflict and thus it is 
not too annoying, I think.

> * In Any Case, Default Exposed Packages Are Also a Poor Compromise.
>
> I don't want to have to worry about accumulating untracked dependcies
> when I am doing quickie work with GHCi.  I want my dependencies
> checked every step of the way and should not have to round trip
> through a Cabal packaging step just to verify them.

Well, a compromise is not poor just because it is a compromise. What you are 
demanding here is IMHO a bit extreme. Why do you think dependency tracking is 
essential for "doing quickie work with GHCi"? I couldn't care less about such 
things whenever I start hacking /anything/, using interpreter or compiler or 
whatever. Later on, when it becomes a larger project, I will use some sort of 
build system anyway, and then there is still plenty of time to care about 
what implementations (packages) exactly I am using.

Ben