On 24 May 2011 14:38, max ulidtko wrote:

Hi haskell-cafe.

I have a package which builds with cabal pretty fine, but there is namespace issue which disturbs me. The problem is that the package exports (to the toplevel namespace!) some modules with fairly general names, like Tests, Basics, Applications. This is probably an oversight of the original package author, and the namespace shouldn't be organised like this... but it is. And I'm looking for a way to avoid potential namespace troubles should I install the package, other than going and reforming the namespace tree myself.

What I was thinking about was some cabal option to "wrap" package's namespace into a toplevel module, say "PackageName", so that module Tests could be imported by usual code with `import PackageName.Tests`. Is that possible with cabal?

Things are further complicated by the numerous intra-library imports. While the "outside" code refers to a module with PackageName.ModuleName, it would be very desirable that "inside" code used just straight ModuleName.

The only real option I can think of is to use GHC's package imports functionality: http://haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#packag... . However, its usage is usually discouraged. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

----- Original Message -----

From: max ulidtko To: haskell-cafe@haskell.org Cc: Sent: Monday, May 23, 2011 11:38 PM Subject: [Haskell-cafe] Cabal: wrapping namespace of a package into top-level module

Hi haskell-cafe.

I have a package which builds with cabal pretty fine, but there is namespace issue which disturbs me. The problem is that the package exports (to the toplevel namespace!) some modules with fairly general names, like Tests, Basics, Applications. This is probably an oversight of the original package author, and the namespace shouldn't be organised like this... but it is. And I'm looking for a way to avoid potential namespace troubles should I install the package, other than going and reforming the namespace tree myself.

Whatever you do, you should mail the package author suggesting a better organization (including a patch, if you do reorganize the module yourself). I think there are three options with current tools 1) If you don't actually want to make modules with those names, it might not be a problem for now. Just like you don't get errors from importing multiple modules with conflicting identifiers unless you actually use the identifiers, there shouldn't be errors if you happen to use two packages defining a module with the same name, unless you actually try to import that module. 2) If you do want to reorganize the package, I think a textual replace changing the old fully-qualified names to the new should work. Here are some suggestions for automating it with various little unix tools, but I haven't tried on a nontrivial package. mkdir -p New/Prefix/ mv $SOURCEDIRS New/Prefix/ sed -n '/exposed-modules/,/:/p' $PKG.cabal | grep -v : | tr -d '[[:blank:]]' > modules awk '{print ",s/"$0"/New.Prefix."$0"/g"} END {print "wq"}' > rename.ed find . -name '*.hs' -exec ed {} < rename.ed \; If you decide to write your program against the current names while waiting for the author to change them, the same sort of thing should work for updating module names in your program. 3) There's also package-qualified imports, but I don't think you should use them - if there are actually conflicts on those top-level module names, the package should be fixed sooner rather than later. www.haskell.org/ghc/docs/7.0.3/html/users_guide/syntax-extns.html#package-imports

What I was thinking about was some cabal option to "wrap" package's namespace into a toplevel module, say "PackageName", so that module Tests could be imported by usual code with `import PackageName.Tests`. Is that possible with cabal?

Things are further complicated by the numerous intra-library imports. While the "outside" code refers to a module with PackageName.ModuleName, it would be very desirable that "inside" code used just straight ModuleName.

It's been discussed before, but not implemented http://hackage.haskell.org/trac/ghc/wiki/Commentary/Packages/PackageMounting... Brandon