Exposed packages and cabal store

[Merivuokko]

What would be the best way to inform hint (and GHC) about packages that are in user's cabal store?
(I'm talking about the most recent cabal versions here.)

I often want to use hint to allow the user to configure or expand my applications with Haskell code.
I want (some/all) modules from my executable and from all dependency packages to be visible to hint.
I also want the user to be able to add whatever packages to their configuration logic that they see fit (as long as those packages don't conflict with the applications' dependencies).

Currently the only solution that I have found is to utilize GHC environment files, which are dynamically generated by cabal exec.
The workflow is this:

1. The user needs to clone my applications repository somewhere.

2. They need to build the package using cabal build.

3. They can then run cabal exec app_name to run the application using hint.

   This makes all dependency packages visible to hint/GHC, but the executable's modules are not visible.
   The user cannot install my application or use cabal run, as then there is no required GHC environment file.
   Using cabal exec slows down the startup time of the application significantly.

4. If the user wants to add their own packages they need to add them to my application's .cabal file as dependencies.

   When rebuilding the application, this will cause "unused package" warnings to be emitted.

So is there a way to solve the following problems:

1. Allow the user to install the application using hint.
2. Allow the user to add new libraries such that they are visible to hint without modifying the application and without opening a dependency hell (because of conflictin packages). New packages can either be imported from system-wide package database or built using cabal.
3. Allow the user to run the application without any cabal files or source code.
4. Allow the modules from the executable to be accessed from within hint.

I acknowledge there might not be a ready solution for these problems, but I wish to hear comments on the subject in order to find a way towards a correct solution.
I believe that resolving these issues would make Haskell run-time evaluation more appealing to both users and developers.
Haskell would be a good extension language and most of the required infrastructure is already in place – some finishing touches remain to integrate the support to the ecosystem.
I am very much open to a solution that would require some support from Cabal.

[Merivuokko]

I should have noted that the cabal build --write-ghc-environment-files=always trick has a problem that it does not install packages to the user's package database and hence requires the source code to be both available and compiled locally.

It also restricts the user by forcing them to run the application in a specific directory.