exposed packages and cabal depends

[Simon Marlow]

On 08 April 2005 22:24, S. Alexander Jacobson wrote:

> The -hide-all-packages option would make sense only if there were real
> flexibility in selecting which packages to use in implementing the
> modules imported into your program.  However, in our discussions, you
> you've defined two rules that eliminate this flexibility:
> 
> * you cannot use two different modules with the same module ID in the
>    same program
> 
> * you cannot use two different packages with the same module ID in the
>    same program
> 
> Together these constraints imply that packages should contain only
> minimal sets of mutually interdependent modules; every additional
> module included in a package restricts its usability.  So, if no two
> packages should contain the same module name, one must therefore
> conclude:
> 
>   Package Dependency Rule: The module names used in a program
>   completely specify the packages required to interpret/compile it.

No, that doesn't follow.  You can most certainly have lots of packages
with the same module, you just can't use them in the same program.

How do you think we plan to have multiple versions of packages?

[ stuff about the -i overriding problem deleted... I'll think about it
and post to a new thread.]

> To be clear, my problem with -hide-all-packages is that it creates
> much greater risk of getting out of sync with the global table.
> Build-depends tags are actively bad because you cannot know the nth
> degree dependencies of the packages you are using.  Correctness is
> only with respect to the global table.

Yes, the user has to know about dependencies because of the overlap
restriction.  But dependencies are completely visible: you *can* know
the dependencies of the packages you're using.  

I'm not sure what you mean by "global table".

One day we'll lift the overlap restriction and things will get easier,
but not right now (unless you have a patch!).

> Yes, I am begging the question of how we construct and manage global
> tables in a way that preserves free-packaging/decentralization.
> (Perhaps it is with user specifiable hackage tables)  But, there is
> no point in talking about solutions until we agree on the problems
> that need to be solved.

At this point I'm a bit hazy on what problem you still think needs to be
solved :-)

We've eliminated untracked dependencies from Cabal packages.  At some
point, we'll generalise package names to URLs (assuming community
agreement and a concrete proposal).  Hackage will be providing a
centralised package repository for those that want it.

Cheers,
	Simon