Skip to content
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

Closed
cdsmith opened this issue Jun 25, 2014 · 3 comments
Closed

GHCJS should be invoked in a sandboxed build environment #4

cdsmith opened this issue Jun 25, 2014 · 3 comments

Comments

@cdsmith
Copy link
Collaborator

cdsmith commented Jun 25, 2014

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.

@cdsmith cdsmith added this to the v0.5 milestone Jun 25, 2014
@cdsmith
Copy link
Collaborator Author

cdsmith commented Sep 7, 2014

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.

@cdsmith cdsmith removed this from the v0.5 milestone Aug 8, 2015
@cdsmith
Copy link
Collaborator Author

cdsmith commented Aug 8, 2015

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.

@cdsmith cdsmith modified the milestone: v0.5 Mar 17, 2016
cdsmith pushed a commit that referenced this issue Apr 24, 2019
Merge with original master
@cdsmith
Copy link
Collaborator Author

cdsmith commented Nov 8, 2019

This is obsolete. I'd actually like to start use cabal v2-build now as soon as possible.

@cdsmith cdsmith closed this as completed Nov 8, 2019
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

1 participant