exposed packages and cabal depends

[S. Alexander Jacobson]

This choice adds complexity without adding value.

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

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

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.

Package names that are not URLs add complexity without value.

-Alex-

______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com






On Thu, 7 Apr 2005, Simon Marlow wrote:

> On 31 March 2005 23:15, Isaac Jones wrote:
>
>> Ian Lynagh mentioned this problem to me a few weeks ago and Alex's
>> thread reminded me of it.  This doesn't really relate to Alex's
>> proposal, so I'm starting a new thread.
>>
>> Let's say that from GHC's perspective, package A is exposed and
>> package B is hidden.  Angela Author creates package C which
>> build-depends on both A and B.  She incorrectly lists the
>> build-depends on B, but not on A.  While building, she doesn't notice,
>> since A is an exposed package.
>>
>> This kinda sucks, since it would be nice to check build-dependencies
>> at build time.  This is very similar to the situation in Debian where
>> a packager doesn't realize that there's a build-dependency on A, since
>> she's already got it installed, but when the auto-builders get to it,
>> the build fails since they don't have A installed.
>>
>> I don't know how to solve this; is there a way to require explicit
>> -package flags for all packages in ghc 6.4?  If there were, say
>> -fhide-all-packages, then cabal could use that while building and
>> Angela would catch the error of her ways much earlier.
>
> I've now added -hide-all-packages.  Cabal can start using this from GHC
> 6.4.1.
>
> Cheers,
> 	Simon
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>