Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bundle an interpreter back-end with the front-end application #10

Open
HeinrichApfelmus opened this issue Oct 21, 2016 · 2 comments
Open

Comments

@HeinrichApfelmus
Copy link
Owner

HeinrichApfelmus commented Oct 21, 2016

Proposal

At the moment, people who wish to install HyperHaskell have to install two things:

  1. The graphical front-end application
  2. A Haskell development environment (GHC + Cabal/Stack + some packages from Hackage)

For experienced users, this is the right approach, because they usually already have a Haskell environment (2) installed, and HyperHaskell should be compatible with it.

However, for absolute beginners, it is probably much more convenient to only install

  1. The graphical front-end application, bundled with a smallish default Haskell development environment.

The idea is that experienced users can still opt to install their own environment (2) and use it with HyperHaskell, but beginners have an easier time getting started if the front-end includes a default environment that does not have to be installed separately.

Implementation

To implement the proposal, we have to bundle the following items with the application bundle

  • The hyper-haskell-server executable
  • A GHC package data base that includes the hyper package

and add a new option "default" to the "Settings" pane of a worksheet. When the user chooses "default", then this bundled package database will be used for evaluating worksheet expressions. If the user chooses any other option ("cabal" or "stack"), then the already established procedure for that option applies, and the bundled package database is ignored.

Adding the "Settings" option is not difficult, but unfortunately, there is a problem with bundling: The executable and package database need to be relocatable, because, in general, people are free to move the front-end application bundle around, there is no fixed location at which it is installed. The problem is that at the time of this writing, Cabal does not fully support relocatable package databases.

Cabal has some preliminary support for relocatable packages, but it's not enough. It seems to work for cabal sandboxes

The GHC for MacOS X project has managed to make at least those packages relocatable that are shipped with GHC. Essentially, it does so by manually overwriting the paths in the package.conf.d database. This may possible for a selected set of packages, but I'm not sure how it interacts with dynamic linking, external C libraries, data-file, or executables. Preliminary experiments suggest that it's not straightforward.

I guess that Haskell for Mac found a (partial) solution to this problem already, but being a proprietary product, I'm not sure if they are willing to share their approach.

@Toxaris
Copy link

Toxaris commented Nov 2, 2016

Stack can install both GHC and Haskell packages in a non-destructive way, so maybe an option could be to bundle Stack with HyperHaskell and then instruct the user to use stack to bootstrap the Haskell environment or include an installer that does this.

@HeinrichApfelmus
Copy link
Owner Author

@Toxaris Essentially, this would correspond to embedding an installer into HyperHaskell that simply runs stack and displays the terminal output in a window. I like the idea. It's less convenient for the user than direct packaging, but it's also easier to implement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants