-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
GHCJS should be invoked in a sandboxed build environment #4
Comments
Getting closer to this one. The new install script now does install a local copy of the full tool chain codeworld/build, including GHC and GHCJS, and the GHC package database. However, GHCJS still registers its own package database in ~/.ghcjs, when ghcjs-boot is run. Cabal also writes some accounting to ~/.cabal, but it's not clear that this matters. Once that is corrected so that the install script can install to a single build directory without modifying global state, it will be possible to deploy new versions of underlying libraries by rebuilding into a fresh working directory. |
This is still a theoretical problem, but since I've moved the data to a separately mountable volume and switched to developing on GCE instances which are easily cloned, it's not really a practical problem. I can just copy the running server to a new instance, do the update there, and then mount the data drive on the other instance. So I'm removing this milestone. |
This is obsolete. I'd actually like to start use cabal v2-build now as soon as possible. |
GHCJS currently runs using the system and user-wide package databases in ~/.ghcjs. This means that updating GHCJS to a new version requires about an hour of downtime while the new GHCJS version is bootstrapped and packages installed.
We should use a sandboxed environment, so that it's possible to rebuild and bootstrap GHCJS, and then copy the environment over in a single operation.
The text was updated successfully, but these errors were encountered: