On 14 June 2005 13:03, Duncan Coutts wrote:
On Mon, 2005-06-13 at 16:06 +0100, Simon Marlow wrote:
This is "fixed" in newer versions of Cabal.
However, you are heading for problems here. When you install a package P that includes a module M, you prevent the user from having any modules called M unless they say '-hide-package P' (see previous discussions on this subject).
For this reason, we strongly recommend using hierarchical module names.
At the moment, Cabal "exposes" all the packages it imports. Perhaps we should have an option to install an unexposed package, to allow installation of packages that contain non-hierarchical module names. Isaac - what do you think?
But remember that any exposed dependent package of P effectively exposes package P anyway. So it's not the case that you can install an unexposed package and assume that it'll all be ok. Any package installed later can come along and expose your package and you're back to the problem that no programs/libs with your module M can now be complied (without several -hide-package flags).
A package is never exposed as a result of being depended on by another package, but its modules are brought into the module namespace. The difference is that you can import modules from an exposed package, you can't from a hidden package. This is true even if the hidden package is depended on by another exposed package. Cheers, Simon
On Wed, 2005-06-15 at 13:15 +0100, Simon Marlow wrote:
But remember that any exposed dependent package of P effectively exposes package P anyway. So it's not the case that you can install an unexposed package and assume that it'll all be ok. Any package installed later can come along and expose your package and you're back to the problem that no programs/libs with your module M can now be complied (without several -hide-package flags).
A package is never exposed as a result of being depended on by another package, but its modules are brought into the module namespace.
The difference is that you can import modules from an exposed package, you can't from a hidden package. This is true even if the hidden package is depended on by another exposed package.
True it is not exposed, but it's being brought into the module namespace. ("effectively expose" was not a good term for what I meant.) The point is, it is the being brought into the module namespace that's the problem. Using a flat module namespace in any library package P can pollute the module namespace for all other programs (even if the library is not exposed by default because any library package Q that uses P and is exposed will bring package P's modules into the module namespace). Then all those modules in package P will clash with modules of the same name in your own program even if you never import anything (directly or indirectly) from package P or Q. As I've mentioned before, the canonical example of this problem is the GetOpt module from the util package (part of the old hslibs collection of packages which use flat module names). If you install any library package (lets call it package "foo-0.1") that uses the util package and is exposed then you can no longer use the module name "GetOpt" in any other program you compile from then on, even if none of that program's modules import any module from package "foo-0.1" or "util". That is, it breaks totally unrelated programs, eg happy in this example. I think the bug in this case is the fact that the modules are considered to be part your program even though they are never imported (directly or indirectly) or even any modules from the same package are imported (if we take the reasonable assumption that if one module from a package becomes part of your program's module namespace then all of them do). Duncan
participants (2)
-
Duncan Coutts -
Simon Marlow